tcc-2

参考：https://mp.weixin.qq.com/s/nM81BRyQRTWab78a6KTD-g

1 TCC 回顾

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

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

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

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 TCC 存在问题

TCC 模式中存在的三大问题是幂等、悬挂和空回滚。在 Seata1.5.0 版本中，增加了一张事务控制表，表名是 tcc_fence_log 来解决这个问题。而在上一节 @TwoPhaseBusinessAction 注解中提到的属性 useTCCFence 就是来指定是否开启这个机制，这个属性值默认是 false。

tcc_fence_log 建表语句如下（MySQL 语法）：

CREATE TABLE IF NOT EXISTS `tcc_fence_log`
(
    `xid`           VARCHAR(128)  NOT NULL COMMENT 'global id',
    `branch_id`     BIGINT        NOT NULL COMMENT 'branch id',
    `action_name`   VARCHAR(64)   NOT NULL COMMENT 'action name',
    `status`        TINYINT       NOT NULL COMMENT 'status(tried:1;committed:2;rollbacked:3;suspended:4)',
    `gmt_create`    DATETIME(3)   NOT NULL COMMENT 'create time',
    `gmt_modified`  DATETIME(3)   NOT NULL COMMENT 'update time',
    PRIMARY KEY (`xid`, `branch_id`),
    KEY `idx_gmt_modified` (`gmt_modified`),
    KEY `idx_status` (`status`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4;

处理幂等

提交事务时首先会判断 tcc_fence_log 表中是否已经有记录，如果有记录，则判断事务执行状态并返回。这样如果判断到事务的状态已经是 STATUS_COMMITTED，就不会再次提交，保证了幂等。如果 tcc_fence_log 表中没有记录，则插入一条记录，供后面重试时判断。

处理空回滚

Seata 的解决方案是在 try 阶段 往 tcc_fence_log  表插入一条记录，status 字段值是 STATUS_TRIED，在 Rollback 阶段判断记录是否存在，如果不存在，则不执行回滚操作。

处理悬挂

悬挂就是由于网络问题，导致的，try指令没有正常通知到rm，导致执行回滚，后来try提示预留资源成功。造成的资源无法正常释放的问题。

Seata 解决这个问题的方法是执行 Rollback 方法时先判断 tcc_fence_log 是否存在当前 xid 的记录，如果没有则向 tcc_fence_log 表插入一条记录，状态是 STATUS_SUSPENDED，并且不再执行回滚操作。

TCC 模式是分布式事务使用最多的模式，但是幂等、悬挂和空回滚一直是 TCC 模式需要考虑的问题，Seata 框架在 1.5.0 版本完美解决了这些问题。

对 tcc_fence_log 表的操作也需要考虑事务的控制，Seata 使用了代理数据源，使 tcc_fence_log 表操作和 RM 业务操作在同一个本地事务中执行，这样就能保证本地操作和对 tcc_fence_log 的操作同时成功或失败。