免费的做网站百度seo网站
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模式还是有全局的行级锁，整体式是串行的。