文章目录
- 微服务框架
- 分布式事务
- 38 动手实践
- 38.6 TCC 模式原理
- 38.6.1 TCC 模式原理
- 38.6.2 举个栗子
- 38.6.3 工作流程
- 38.6.4 总结
38 动手实践
38.6 TCC 模式原理
38.6.1 TCC 模式原理
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。【虽然AT 模式是自动实现,但是AT 需要在第一阶段生成快照,第二阶段回滚时再进行恢复,这样也会影响性能】
需要实现三个方法:
- Try:资源的检测和预留;
- Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功。
- Cancel:预留资源释放,可以理解为try的反向操作。
38.6.2 举个栗子
举例,一个扣减用户余额的业务。假设账户A原来余额是100,需要余额扣减30元。
- 阶段一( Try【资源检测和预留】 ):检查余额是否充足,如果充足则冻结金额增加30元,可用余额扣除30
冻结金额 + 可用余额 = 总余额
- 阶段二:假如要提交(Confirm),则冻结金额扣减30
第二阶段仅仅操作的是 冻结金额
- 阶段二:如果要回滚(Cancel),则冻结金额扣减30,可用余额增加30
TCC 模式在完成了资源的预留后,后面都是对冻结金额进行操作【事务之间没有影响】
即TCC 模式不用加锁就实现了隔离
38.6.3 工作流程
依然是这三个 组成的模型
1.1 ~ 1.3 都是一样的,一开始都是TM 去开启并注册全局事务到TC 事务协调者,接着TM 去通知每一个RM 执行分支事务,RM 要先到TC 去注册一下分支事务
执行的时候:
1.4 第一阶段,资源预留try
完成后它 会直接进行提交,提交完之后向 TC 事务协调者报告事务状态
OK其实到这里,第一阶段就结束了
第二阶段开始
TM 会去告知TC 事务执行完了,该提交了
TC 就会去判断检查 分支事务的状态,看看这些分支的资源是否满足
如果够,那就直接进行提交操作
如果不够,则执行回滚操作【cancel】
【T 、C 、C 三段逻辑需要人工进行编写】
38.6.4 总结
TCC模式的每个阶段是做什么的?
- Try:资源检查和预留
- Confirm:业务执行和提交
- Cancel:预留资源的释放
TCC的优点是什么?
- 一阶段完成直接提交事务,释放数据库资源,性能好
- 相比AT模型,无需生成快照,无需使用全局锁,性能最强
- 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库
TCC的缺点是什么?
- 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦
- 软状态,事务是最终一致
- 需要考虑Confirm和Cancel的失败情况,做好幂等处理