微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

分布式事务

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

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

2. 阶段二：假如要提交（Confirm），则冻结金额扣减30

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

3. 阶段二：如果要回滚（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的失败情况，做好幂等处理