分布式事务基础理论——TCC

什么是TCC事务

TCC是 try、confirm、cancel三个单词的缩写。

TCC要求每个分支事务实现三个操作：

• 预处理【try】：try是业务检查和资源预留的操作
• 确认【confirm】：confirm是业务确认操作
• 撤销【cancel】：cancel是实现一个与try相反的操作，即回滚

但是我个人感觉TCC和AT实际的执行过程很相像鸭~

TCC执行原理

Try阶段

• 首先在TCC中，还是存在【全局事务管理】的角色，资源1和2还是指代【事务参与者】
• 在TCC分布式事务执行中，【全局事务管理】会让每一个【事务参与者】都执行一个try的操作进行业务检查和资源预留，如：
  • 张三要给李四转100块钱，张三需要首先检查自己的卡里是不是有100块钱
  • 下单操作的时候，检查库存是否满足订单的数量，如果满足，还可以进行预留

Confirm阶段

• 当【事务参与者】在【Try】阶段都执行成功，全局事务进行到下一个阶段【Confirm】
• 进入【Confirm】阶段，【全局事务管理】会像【事务参与者】进行确认提交事务
• 在【Confirm】阶段中，只要各个【事务参与者】在【Try】阶段是执行成功的，就默认认为【Confirm】阶段也一定成功

Cancel阶段

Cancel阶段就是回滚阶段，以上图为例：

当有一个或者多个【事务参与者】的【Try】阶段执行失败，就开始全局回滚：即其他【事务参与者】开始进行回滚

总结

• 【Try】阶段是做业务检查（一致性）以及资源预留（隔离），此阶段仅是一个初步操作，它和后续的【Confirm】一起才能构成一个完整的业务逻辑
• 【Confirm】阶段的确认操作，是在所有【事务参与者】的【Try】操作都执行完毕后才进行的。通常情况下，TCC认为【Confirm】阶段是不会出现问题的：即只要【Try】成功，【Confirm】也是一定成功的。如果【Confirm】执行失败，就会需要重试机制，或者人工处理。
• 【Cancel】阶段是在业务执行错误需要回滚的情况下才会进行的，会执行【分支事务】的业务取消、预留资源释放操作。通常情况下，TCC认为【Cancel】阶段也是不会出现问题的，如果【Confirm】执行失败，就会需要重试机制，或者人工处理。

TCC事务管理器

TCC的【TM】是需要独立部署的，也可以让全局事务的发起者充当TM的角色

【TM】在发起全局事务时生成全局事务记录，【全局事务ID】贯穿整个分布式事务调用链条，用来记录事务上下文，追踪记录事物的状态。在TCC中，【Confirm】和【Cancel】是必须执行成功的，一旦这两个阶段执行失败，就需要重试，这时就必须实现操作的幂等性（幂等性是指同一个操作不管请求多少次，其执行结果始终是一样的）。