分布式事务系列--是选TCC还是SAGA
发布日期:2021-06-30 11:08:01
浏览次数:2
分类:技术文章
本文共 1047 字,大约阅读时间需要 3 分钟。
byteTCC框架,支持两种模式,一种是TCC模式,一种是SAGA模式,二者如何选择,是一个取舍问题,没有完美方案。
1.TCC模式
这种模式下,我们需要操作的目标字段,都要添加一个相关的冻结字段,try操作是操作冻结字段,cc操作时,将冻结的数值更新到目标字段。
示例如下:UPDATE company SET frozen = frozen + #{money} WHERE id = #{id} UPDATE company SET money = money + #{money},frozen = frozen - #{money} WHERE id = #{id} UPDATE company SET frozen = frozen - #{money} WHERE id = #{id}
2.SAGA模式
这种模式,是使用一个反向的业务操作,来撤销之前的业务操作。SAGA模式,try阶段直接操作目标字段,不需要使用冻结字段,和TCC模式相比,saga不需要confirm操作。
3.对比
设想一种场景:A->B,C,D。这种场景下,如果发生如下情况:
- 1.B,C的try成功了,但是D的try失败了;
- 2.此时另外的用户来读取BCD的值;
- 3.ABCD进行回滚;
显然,不管是TCC还是SAGA模式,try出问题了,都会进入cancel阶段,但是,恰巧,在BC刚try成功D失败了,但是还未来得及回滚的情况下,有用户来读取BCD的值。
那么,这种情况下,使用TCC和SAGA,结果是不一样的。
在TCC中,由于try操作的是冻结字段,所以,其他用户在try和cancel的间隙来读数据,那么读的数据也是正确的,因为目标字段并没有发生改变。
在SAGA中,由于直接操作的目标字段,所以,try阶段,由于数据已经提交了,那么其他用户在try和cancel的间隙来读取数据,读到的数据,就是有问题的“脏数据”。
4.结论
1.TCC模式下
- 缺点:开发麻烦,因为每个目标字段都需要一个冻结字段来支撑事务操作;
- 优点:不存在上述脏数据的问题;
2.SAGA模式下
- 缺点:数据没有很好的隔离,有脏数据的风险;
- 优点:开发简单,不需要预留冻结字段;
当然,看起来只有在2PC模型下,才不存在这个“脏读风险”。
关于这个问题,推荐几篇文章看看:
转载地址:https://it4all.blog.csdn.net/article/details/88572986 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!
发表评论
最新留言
做的很好,不错不错
[***.243.131.199]2024年05月01日 01时47分48秒
关于作者
喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!
推荐文章
python 变量类型
2019-04-30
Python int() 函数
2019-04-30
scrapy 框架安装
2019-04-30
关于Java接口interface定义的几点说明
2019-04-30
关于 Android 程序使用 Support Library 属性的几点说明
2019-04-30
Android AsyncTask 异步任务取消
2019-04-30
Asp.net 解决表单提交之后 页面刷新会再次提交表单
2019-04-30
解决js 写入中文乱码
2019-04-30
Java查找Map中的日期时间里当前时间最远
2019-04-30
安装openfire教程
2019-04-30
Android support v7 ActionBarActivity 过时
2019-04-30
Android Studio 导入第三方库
2019-04-30
Sql Server 查询一段日期内的所有礼拜天
2019-04-30
golang testing
2019-04-30
阅读protobuf-go代码
2019-04-30
golang反射基本准则
2019-04-30
2020-11-30-golang并发模式context
2019-04-30
知名定律摘要-持续更新
2019-04-30
golang value part
2019-04-30