阿里Seata新版本终于解决了TCC模式的幂等、悬挂和空回滚问题

今天来聊一聊阿里巴巴 Seata 新版本（1.5.0）是怎么解决的的 TCC 模式下的幂等、悬挂和空回滚问题的。

1 TCC 回顾

TCC 模式是最经典的分布式事务解决方案，它将分布式事务分为两个阶段来执行，try 阶段对每个分支事务进行预留资源，如果所有分支事务都预留资源成功，则进入 commit 阶段提交全局事务，如果有一个节点预留资源失败则进入 cancel 阶段回滚全局事务。

以传统的订单、库存、账户服务为例，在 try 阶段尝试预留资源，插入订单、扣减库存、扣减金额，这三个服务都是要提交本地事务的，这里可以把资源转入中间表。在 commit 阶段，再把 try 阶段预留的资源转入最终表。而在 cancel 阶段，把 try 阶段预留的资源进行释放，比如把账户金额返回给客户的账户。

注意：try 阶段必须是要提交本地事务的，比如扣减订单金额，必须把钱从客户账户扣掉，如果不扣掉，在 commit 阶段客户账户钱不够了，就会出问题。

1.1 try-commit

try 阶段首先进行预留资源，然后在 commit 阶段扣除资源。如下图：

1.2 try-cancel

try 阶段首先进行预留资源，预留资源时扣减库存失败导致全局事务回滚，在 cancel 阶段释放资源。如下图：

2 TCC 优势

TCC 模式最大的优势是效率高。TCC 模式在 try 阶段的锁定资源并不是真正意义上的锁定，而是真实提交了本地事务，将资源预留到中间状态，并不需要阻塞等待，因此效率比其他模式要高。

同时 TCC 模式还可以进行如下优化：

2.1 异步提交

try 阶段成功后，立即进入 confirm/cancel 阶段，而是认为全局事务已经结束了，启动定时任务来异步执行 confirm/cancel，扣减或释放资源，这样会有很大的性能提升。

2.2 同库模式

TCC 模式中有三个角色：

• TM：管理全局事务，包括开启全局事务，提交/回滚全局事务；
• RM：管理分支事务；
• TC: 管理全局事务和分支事务的状态。

下图来自 Seata 官网：

TM 开启全局事务时，RM 需要向 TC 发送注册消息，TC 保存分支事务的状态。TM 请求提交或回滚时，TC 需要向 RM 发送提交或回复消息。这样包含两个个分支事务的分布式事务中，TC 和 RM 之间有四次 RPC。

优化后的流程如下图：

TC 保存全局事务的状态。TM 开启全局事务时，RM 不再需要向 TC 发送注册消息，而是把分支事务状态保存在了本地。TM 向 TC 发送提交或回滚消息后，RM 异步线程首先查出本地保存的未提交分支事务，然后向 TC 发送消息获取（本地分支事务所在地）全局事务状态，以决定是提交还是回滚本地事务。

这样优化后，RPC 次数减少了 50%，性能大幅提升。

3 RM 代码示例

以库存服务为例，RM 库存服务接口代码如下：

@LocalTCC
public interface StorageService {

    /**
     * 扣减库存
     * @param xid 全局xid
     * @param productId 产品id
     * @param count 数量
     * @return
     */
    @TwoPhaseBusinessAction(name = "storageApi", commitMethod = "commit", rollbackMethod