seata的TCC模式分析

TCC是 Try- Confirm-Cancel 这3个名词的首字母简称，是一个2阶段提交的变体思路。

Try：对资源的检查和预留；

Confirm: 确认对预留资源的消耗，执行业务操作；

Cancel：预留资源的释放；

TCC的事务交互过程和AT类似，业务先发起全局事务，向TC申请全局XID，再把这个全局XID传递给各个微服务，各微服务在进行本地第一阶段处理之前，都要向

TCC模式最重要的事情就是要把自己的业务模型都拆分为2个阶段，能够支持预留和确认两个阶段，并且需要自行编码来实现try-confirm-cancel对应的业务逻辑，深度侵入业务和代码，当然带来的好处也非常明显，相比AT模式可以大大提高并发度。

常见的电商下单案例中，涉及商品库存扣减、账户金额扣扣减、订单创建 这3大业务，3个业务要支持TCC，首要的是把业务模型拆分为两阶段。

1、库存扣减 2阶段模型

     需要把库存拆分为3部分： 实际库存、可售库存、冻结库存

     其中 实际库存 = 可售库存+ 冻结库存

     Try：增加冻结库存、减少可售库存、实际库存保持不变

     Confirm： 什么都不做；

     Cancel：减少冻结库存，增加可售库存，实际库存不变；

2、账户金额扣减的2阶段模型和库存扣减完全一致。

3、订单创建 2阶段模型

     订单需要增加一个 创建中 状态。

     Try : 订单数据插入DB中，但是订单状态为 创建中；

     Confirm：订单状态变更为 正常状态；

     Cancel：订单状态变更为  无效状态

TCC模式，第1阶段库存、账户、订单这3者其实都是各自提交了本地事务，没有全局锁什么事，第2阶段，无论是Confirm还是Cancel 也都是本地事务提交，也没有全局事务什么事，基于这种模式对于各自业务的总体并发度几乎没有影响，不像AT模式还是有全局的行级锁，整体式是串行的。