Seata之TCC模式解读

目录

基本介绍

起源

概述

案例流程分析

TCC注意事项

空回滚

幂等

悬挂

具体使用 

@LocalTCC

@TwoPhaseBusinessAction  

小结 

---

基本介绍

起源

关于TCC的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，其注册了TCC商标。
 

概述

TCC是Try-Confirm-Cancel的简称。 

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

• Try：资源的检测和预留。做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。

• Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则 认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。

• Cancel：预留资源释放，可以理解为try的反向操作。在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采 用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理。

TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel 操作若执行失败，TM会进行重试。 

与AT模式与TCC模式的对比 

	AT模式	TCC模式
一阶段 prepare	在本地事务中，一并提交业务数据更新和相应回滚日志记录	调用 自定义的 prepare 逻辑
二阶段 commit	马上成功结束，自动异步批量清理回滚日志	调用 自定义的commit 逻辑
二阶段 rollback	通过回滚日志，自动 生成补偿操作，完成数据回滚。	调用 自定义的rollback 逻辑
其他	支持本地 ACID 事务 的 关系型数据库	不依赖于底层数据资源的事务支持

TCC支持把自定义的分支事务纳入到全局事务的管理中。 

案例流程分析

假设一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。

 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

 

总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。

阶段二（Confirm)：，现在库存充足，可以提交（Confirm），则冻结金额扣减30确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了

阶段二(Canncel)：如果库存不足，需要回滚（Cancel），则冻结金额扣减30，可用余额增加30需要回滚，那么就要释放冻结金额，恢复可用金额：

TCC注意事项

空回滚

• 在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回 滚，然后直接返回成功。
• 出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶 段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
• 解决思路是关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回 滚；如果没执行，那就是空回滚。前面已经说过TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分 布式事务调用链条。再额外增加一张分支事务记录表，其中有全局事务 ID 和分支事务 ID，第一阶段 Try 方法里会 插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存 在，则是空回滚。

幂等

• 为了保证TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、 Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据 不一致等严重问题。
• 解决思路在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态。

悬挂

• 悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。
• 出现原因是在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵， 通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求 才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预 留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。
• 解决思路是如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支 事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

具体使用 

@LocalTCC

该注解需要添加到上面描述的接口上，表示实现该接口的类被 seata 来管理，seata 根据事务的状态，自动调用我们定义的方法，如果没问题则调用 Commit 方法，否则调用 Rollback 方法。

@LocalTCC
public interface AccountTCCService {

}

@TwoPhaseBusinessAction  

该注解用在接口的 Try 方法上，该注解的用法如下:

@LocalTCC
public interface AccountTCCService {

    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money")int money);

    boolean confirm(BusinessActionContext ctx);

    boolean cancel(BusinessActionContext ctx);
}

该注解包含这几个属性

• name 为 tcc 方法的 bean 名称，需要全局唯一，一般写方法名即可；
• commitMethod 自然地写 Commit 方法的方法名；
• rollbackMethod 写 Rollback 方法的方法名； 

@BusinessActionContextParameter
该注解用来修饰 Try 方法的入参，被修饰的入参可以在 Commit 方法和 Rollback 方法中通过 BusinessActionContext 获取。 

最后对接口进行实现即可：

@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountMapper accountMapper;
    @Autowired
    private AccountFreezeMapper freezeMapper;

    @Override
    @Transactional
    public void deduct(String userId, int money) {
        // 0.获取事务id
        String xid = RootContext.getXID();
        // 1.扣减可用余额
        accountMapper.deduct(userId, money);
        // 2.记录冻结金额，事务状态
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);
        freeze.setState(AccountFreeze.State.TRY);
        freeze.setXid(xid);
        freezeMapper.insert(freeze);
    }

    @Override
    public boolean confirm(BusinessActionContext ctx) {
        // 1.获取事务id
        String xid = ctx.getXid();
        // 2.根据id删除冻结记录
        int count = freezeMapper.deleteById(xid);
        return count == 1;
    }

    @Override
    public boolean cancel(BusinessActionContext ctx) {
        // 0.查询冻结记录
        String xid = ctx.getXid();
        AccountFreeze freeze = freezeMapper.selectById(xid);

        // 1.恢复可用余额
        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
        // 2.将冻结金额清零，状态改为CANCEL
        freeze.setFreezeMoney(0);
        freeze.setState(AccountFreeze.State.CANCEL);
        int count = freezeMapper.updateById(freeze);
        return count == 1;
    }
}

小结 

性能：好

模式：AP,存在数据不一致的中间状态

难易程度：复杂，SEATA TC只负责全局事务的提交与回滚指令，具体的回滚处理全靠程序员自己实现(手动写代码)

使用要求：

• 所有服务与数据库必须要自己拥有管理权
• 支持异构数据库，可以使用不同选型实现