实战，阿里神器 Seata 实现 TCC模式 解决分布式事务，真香

今天这篇文章介绍一下Seata如何实现TCC事务模式，文章目录如下：

什么是TCC模式？

TCC（Try Confirm Cancel）方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。

TCC分为两个阶段，分别如下：

• 第一阶段：Try（尝试），主要是对业务系统做检测及资源预留 (加锁，锁住资源)
• 第二阶段：本阶段根据第一阶段的结果，决定是执行confirm还是cancel
• Confirm（确认）：执行真正的业务（执行业务，释放锁）
• Cancle（取消）：是预留资源的取消（出问题，释放锁）

为了方便理解，下面以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建 2 个步骤，库存服务和订单服务分别在不同的服务器节点上。

假设商品库存为 100，购买数量为 2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。

①Try 阶段

TCC 机制中的 Try 仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：

• 完成所有业务检查( 一致性 ) 。
• 预留必须业务资源( 准隔离性 ) 。
• Try 尝试执行业务。

②Confirm / Cancel 阶段

根据 Try 阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。

Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成。

Confirm：当 Try 阶段服务全部正常执行， 执行确认业务逻辑操作，业务如下图：

这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为，如果在 Try 阶段能正常的预留资源，那 Confirm 一定能完整正确的提交。

Confirm 阶段也可以看成是对 Try 阶段的一个补充，Try+Confirm 一起组成了一个完整的业务逻辑。

Cancel：当 Try 阶段存在服务执行失败， 进入 Cancel 阶段，业务如下图：

Cancel 取消执行，释放 Try 阶段预留的业务资源，上面的例子中，Cancel 操作会把冻结的库存释放，并更新订单状态为取消。

以上便是TCC模式的全部概念，这部分内容在陈某之前的文章也是详细的介绍过：对比7种分布式事务方案，还是偏爱阿里开源的Seata，真香！(原理+实战)

TCC模式的三种类型？

业内实际生产中对TCC模式进行了扩展，总结出了如下三种类型，其实从官方的定义中无此说法，不过是企业生产中根据实际的需求衍生出来的三种方案。

1、通用型 TCC 解决方案

通用型TCC解决方案是最经典的TCC事务模型的实现，正如第一节介绍的模型，所有的从业务都参与到主业务的决策中。

适用场景：

由于从业务服务是同步调用，其结果会影响到主业务服务的决策，