文章目录

  • 微服务框架
  • 分布式事务
  • 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元。

  1. 阶段一( Try【资源检测和预留】 ):检查余额是否充足,如果充足则冻结金额增加30元,可用余额扣除30

springcloud分布式事务解决_spring cloud

冻结金额 + 可用余额 = 总余额

  1. 阶段二:假如要提交(Confirm),则冻结金额扣减30

springcloud分布式事务解决_seata_02

第二阶段仅仅操作的是 冻结金额

  1. 阶段二:如果要回滚(Cancel),则冻结金额扣减30,可用余额增加30

springcloud分布式事务解决_springcloud分布式事务解决_03

TCC 模式在完成了资源的预留后,后面都是对冻结金额进行操作【事务之间没有影响】

即TCC 模式不用加锁就实现了隔离

38.6.3 工作流程

springcloud分布式事务解决_架构_04

依然是这三个 组成的模型

springcloud分布式事务解决_架构_05

1.1 ~ 1.3 都是一样的,一开始都是TM 去开启并注册全局事务到TC 事务协调者,接着TM 去通知每一个RM 执行分支事务,RM 要先到TC 去注册一下分支事务

执行的时候:

1.4 第一阶段,资源预留try

springcloud分布式事务解决_spring cloud_06

完成后它 会直接进行提交,提交完之后向 TC 事务协调者报告事务状态

springcloud分布式事务解决_架构_07

OK其实到这里,第一阶段就结束了

第二阶段开始

springcloud分布式事务解决_spring cloud_08

TM 会去告知TC 事务执行完了,该提交了

springcloud分布式事务解决_架构_09

TC 就会去判断检查 分支事务的状态,看看这些分支的资源是否满足

springcloud分布式事务解决_微服务_10

如果够,那就直接进行提交操作

springcloud分布式事务解决_springcloud分布式事务解决_11

如果不够,则执行回滚操作【cancel】

【T 、C 、C 三段逻辑需要人工进行编写】

38.6.4 总结

TCC模式的每个阶段是做什么的?

  • Try:资源检查和预留
  • Confirm:业务执行和提交
  • Cancel:预留资源的释放

TCC的优点是什么?

  • 一阶段完成直接提交事务,释放数据库资源,性能好
  • 相比AT模型,无需生成快照,无需使用全局锁,性能最强
  • 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库

TCC的缺点是什么?

  • 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦
  • 软状态,事务是最终一致
  • 需要考虑Confirm和Cancel的失败情况,做好幂等处理