分布式事务(1)基本概念
分布式事务(2)两阶段提交
分布式事务(3)TCC方案
分布式事务(4)可靠消息最终一致性
分布式事务(5)最大努力通知
分布式事务【3】TCC方案
4.1.什么是TCC事务
TCC是 Try、Confirm、Cancel 三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。
Try操作 做 业务检查及资源预留；Confirm 做 业务确认操作；Cancel 实现一个与Try相反的操作即 回滚操作。
TM首先发起所有的分支事务的 try操作，任何一个分支事务的 try操作执行失败，TM将会发起所有分支事务的 Cancel操作，若 try操作全部成功，TM将会发起所有分支事务的 Confirm操作，其中 Confirm/Cancel操作 若执行失败，TM会进行重试。
分支事务失败的情况：
TCC分为三个阶段：
- Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的 Confirm 一起才能真正构成一个完整的业务逻辑。
- Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。
- Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为 Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。
- TM事务管理器
TM事务管理器可以实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公用组件，是为了考虑系统结构和软件复用。
TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于 Confirm 和 Cancel 失败需进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求多少次，其结果都相同。
4.2.TCC 解决方案
| 框架名称 | Gitbub地址 | star数 |
|---|---|---|
| Seata之TCC | —— | —— |
TCC-transaction |
https://github.com/changmingxie/tcc-transaction | 5.6k |
Hmily |
https://github.com/yu199195/hmily | 4k |
ByteTCC |
https://github.com/liuyangming/ByteTCC | 2.9k |
EasyTransaction |
https://github.com/QNJR-GROUP/EasyTransaction | 2.3k |