try 阶段：做资金的检测和预留. 检测就是判断余额够不够（当前余额为 100，要扣 30 肯定是够的）. 预留就是说如果余额充足，就先把要扣的 30 元金额冻结起来，也就是说可用余额扣减 30，冻结金额增加 30，而总金额是没有变化的.
confirm 阶段：如果 try 阶段执行成功了，就会执行 confirm 进行提交. 这里就提交就是直接把 try 阶段冻结的 30 元金额直接扣掉，因此总金额就变成 70 元了.
cancel 阶段：如果有人在执行 try 阶段失败了，就要执行 cancel 进行回滚. 这里就是对 try 阶段的一个反向操作. 在 try 阶段冻结的30元余额解冻，可用余额也就增加了 30. 因此从 try 到 cancel 可以看到总金额是没有变化的，变化的仅仅是冻结的部分.

对比 TCC 和 AT 模式的一致性和隔离性

一致性：首先第一阶段两个模式都是各自提交各自的事务，因此两种模式都有可能出现提交成功和失败的情况，导致状态不一致，需要通过第二阶段来调整. 也就是说这两种模式都是最终一致性.

隔离性：AT 模式是需要通过加锁实现隔离（在第一、第二阶段持有全局锁），而 TCC 模式下不需要加锁隔离，因为在第一阶段是通过冻结来实现隔离（冻结了一部分金额），就算此时有另一个事务也要冻结金额，那就直接从可用余额中取一部分冻结，所以事务之间都没有任何影响，不需要加锁，那么 TCC 模式的性能就要比 AT 模式好很多了.

TC 的工作模型

第一阶段：

这里大部分都和 AT 很像，一开始都是由 TM 去开启全局事务并注册到 TC 上面，然后 TM 去通知每一个分支事务去执行，然后请求被 RM 拦截，RM 就会先去注册分之十五，然后去执行 try 预留资源，执行完后直接提交，随后向 TC 报告事务的状态（资源预留执行成功了？还是失败了）.

第二阶段：

TM 通知 TC 事务结束了，那么 TC 就要对事务的状态做判断了. 如果分支预留资源成功了，就直接执行 confirm 提交即可；如果发现其中任意一个有问题，就要执行 cancel 逻辑.

1.2.2、TCC 模式优缺点

优点：

性能高：第一阶段执行完直接提交事务，并且既不用生成快照，也不用使用全局锁. 可以认为是所有分布式事务模型中性能最好的.

不依赖数据库：不需要依赖于事务性的数据库，因为是靠预留资源来做代偿的. 也就是说不仅可以使用 Mysql 这种关系型数据库，也可以使用 Redis 这种非关系型数据库去实现 TCC 模式.

缺点：

代码侵入高：try、confirm、cancel 这三个方法需要人工编写.

软状态，最终一致：第一阶段执行完后，直接提交事务.

考虑幂等：将来 confirm 和 cancel 可能会执行失败，Seata 看到失败了就会重试，就可能造成死循环. 因此要考虑各种健壮性.

1.2.3、TCC 模式注意事项：空回滚

问题：

在将执行某个分支事务的时候，发现执行分支事务的请求因为某种原因（网络抖动）阻塞住了，一旦阻塞的时间超过了超时时间，就会将超时的错误报告给 TC，然后 TC 就会告诉这个分支事务的 RM：“那你去回滚吧”，此时 RM 就会去执行 cancel 的业务.

这就导致本身你没有执行 try 预留资源，现在却要执行 cancel 去释放预留资源. 比方说 try 的业务就是去冻结 30 元的余额，但是在没有进行 try 之前却要进行释放 30 元冻结余额的业务，这不就出事了吗？

解决方案：

因此这里需要做一个空回滚.

在 try 执行请求因为某种原因阻塞时，可能会导致全局事务超时，从而先触发了 cancel 逻辑，此时根本就没有做资源预留，就不能回滚，并且也不能报错（不然 Seata 会以为 cancel 出问题了，会重试，最后导致死循环）. 那么空回滚只需要我们返回一个正常结束即可.

1.2.4、TCC 模式注意事项：业务悬挂

问题：

在执行完空回滚之后，try 逻辑的请求阻塞突然通畅，就会去执行资源预留业务，但是资源预留了之后就没有后续了（已经执行过 cancel 中的空回滚了），既没有 cancel，也没有 confirm，业务只执行了一半. 这就是业务悬挂.

比如说我本来有 100 元余额，执行完空回滚后，try逻辑突然通常，冻结了我 30 元的可用余额，然后也没有后续业务了，就导致我这 30 元有是有，但是却一直用不了.

解决办法：

在执行 try 的时候，先判断一下是否回滚过，如果回滚过了 try 就不能执行了. 同样在执行 cancel 的时候，需要判断一下，try 是不是已经执行了，如果 try 没有执行，就去做一个空回滚.

怎么知道 try 到底有没有执行过呢？这就需要在数据库中在创建一个表，用来记录事务的状态（记录上一步是执行了 try 呢？还是cancel？还是confirm？）.

1.2.5、实现 TCC 模式

案例：在用户余额扣减服务中，实现 TCC 模式.

那么实现的思路如下：

try：扣减可用余额，添加冻结金额.
confirm：删除冻结金额.
cancel：恢复可用金额，删除冻结金额.
注意事项：保证 confirm、cancel 接口的幂等性，注意空回滚和业务悬挂.

实现案例

a）TCC 的 try、confirm、cancel 方法都需要在接口中基于注解来声明

语法如下：

@LocalTCCpublic interface TCCService {        @TwoPhaseBusinessAction(name = "prepare", commitMethod = "confirm", rollbackMethod = "cancel")    void prepare(@BusinessActionContextParameter(paramName = "param") String param);        boolean confirm (BusinessActionContext context);        boolean cancel (BusinessActionContext context);}

根据上述语法，就可以编写用户余额冻结服务的接口 AccountTCCService ，如下

@LocalTCCpublic 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);}

b）建表

这里我们已经有了用户金额表，如下：

这里我们还需要创建用户冻结金额表，如下：

CREATE TABLE `account_freeze_tbl`  (  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,  `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,  `freeze_money` int(11) UNSIGNED NULL DEFAULT 0,  `state` int(1) NULL DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',  PRIMARY KEY (`xid`) USING BTREE) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;

对应实体类如下：

@Data@TableName("account_freeze_tbl")public class AccountFreeze {    @TableId(type = IdType.INPUT)    private String xid;    private String userId;    private Integer freezeMoney;    private Integer state;    public static abstract class State {        public final static int TRY = 0;        public final static int CONFIRM = 1;        public final static int CANCEL = 2;    }}

c）对应刚刚上述所描述的实现思路，可以基本实现（未考虑空回滚和业务悬挂）

AccountTCCService 接口，如下：

@Slf4j@Servicepublic class AccountTCCServiceImpl implements AccountTCCService {    @Autowired    private AccountMapper accountMapper;    @Autowired    private AccountFreezeMapper freezeMapper;    @Override    @Transactional    public void deduct(String userId, int money) {        //1.获取事务 id        String xid = RootContext.getXID();        //2.扣减可用余额        accountMapper.deduct(userId, money);        //3.增加冻结金额，并记录当前事务的状态        AccountFreeze freeze = new AccountFreeze();        freeze.setUserId(userId);        freeze.setXid(xid);        freeze.setFreezeMoney(money);        freeze.setState(AccountFreeze.State.TRY);        freezeMapper.insert(freeze);    }    @Override    public boolean confirm(BusinessActionContext ctx) {        //1.添加事务 id        String xid = RootContext.getXID();        //2.根据 id 删除冻结记录        int count = freezeMapper.deleteById(xid);        return count == 1;    }    @Override    public boolean cancel(BusinessActionContext ctx) {        //1.查询冻结记录        String xid = RootContext.getXID();        AccountFreeze freeze = freezeMapper.selectById(xid);        //2.恢复可用余额        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());        //3.清理冻结余额，状态修改为 cancel        freeze.setFreezeMoney(0);        freeze.setState(AccountFreeze.State.CANCEL);        int count = freezeMapper.updateById(freeze);        return count == 1;    }}

d）考虑空回滚

考虑在执行 try 逻辑阻塞超时，执行了 cancel 逻辑，那么就需要考虑空回滚. 主要记录 cancel 状态即可.

    @Override    public boolean cancel(BusinessActionContext ctx) {        //1.查询冻结记录        String xid = RootContext.getXID();        AccountFreeze freeze = freezeMapper.selectById(xid);        //a. 空回滚判断        if (freeze == null) {            //这里主要记录当前的 cancel 状态            freeze = new AccountFreeze();            //这里能拿到 userId 和 money 是因为在 AccountTCCService 接口中通过 BusinessActionContextParameter 注解注册了            String userId = ctx.getActionContext("userId").toString();            freeze.setUserId(userId);            freeze.setXid(xid);            freeze.setFreezeMoney(0);            freeze.setState(AccountFreeze.State.TRY);            freezeMapper.insert(freeze);        }        //2.恢复可用余额        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());        //3.清理冻结余额，状态修改为 cancel        freeze.setFreezeMoney(0);        freeze.setState(AccountFreeze.State.CANCEL);        int count = freezeMapper.updateById(freeze);        return count == 1;    }

e）幂等问题

第一次超时了，进行空回滚（添加 freeze，设置状态为 cancel），第二次又超时了，freeze 不为空，就会进行恢复金额逻辑. 这就出问题了，不能进行恢复金额操作，因此，这里需要进行判断，如果处理过了，直接返回 true 即可.

    @Override    public boolean cancel(BusinessActionContext ctx) {        //1.查询冻结记录        String xid = RootContext.getXID();        AccountFreeze freeze = freezeMapper.selectById(xid);        //a. 空回滚判断        if (freeze == null) {            //这里主要记录当前的 cancel 状态            freeze = new AccountFreeze();            //这里能拿到 userId 和 money 是因为在 AccountTCCService 接口中通过 BusinessActionContextParameter 注解注册了            String userId = ctx.getActionContext("userId").toString();            freeze.setUserId(userId);            freeze.setXid(xid);            freeze.setFreezeMoney(0);            freeze.setState(AccountFreeze.State.TRY);            freezeMapper.insert(freeze);        }        //b.幂等问题：第一次超时了，进行空回滚，第二次又超时了，freeze 不为空，就会进行恢复金额逻辑(这就出问题了).        if(freeze.getState() == AccountFreeze.State.CANCEL) {            //已经处理过依次 cancel 了，无需重复处理            return true;        }        //2.恢复可用余额        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());        //3.清理冻结余额，状态修改为 cancel        freeze.setFreezeMoney(0);        freeze.setState(AccountFreeze.State.CANCEL);        int count = freezeMapper.updateById(freeze);        return count == 1;    }

confirm 为什么不考虑幂等了？

因为 confirm 逻辑是删除冻结记录，底层就是 sql 调用 delete. 因此即使操作多次，也无妨.

f）业务悬挂问题

处理过 cancel 之后，就没必要再处理 try 了，因此这里只需要判断 freeze 是否存在冻结记录，如果有，拒绝即可.

    @Override    @Transactional    public void deduct(String userId, int money) {        //1.获取事务 id        String xid = RootContext.getXID();        //a. 业务悬挂问题处理：判断 freeze 中是否有冻结记录，如果有，一定是 cancel 执行过，要拒绝业务        AccountFreeze oldFreeze = freezeMapper.selectById(xid);        if(oldFreeze != null) {            return;        }        //2.扣减可用余额        accountMapper.deduct(userId, money);        //3.增加冻结金额，并记录当前事务的状态        AccountFreeze freeze = new AccountFreeze();        freeze.setUserId(userId);        freeze.setXid(xid);        freeze.setFreezeMoney(money);        freeze.setState(AccountFreeze.State.TRY);        freezeMapper.insert(freeze);    }

g）到此，整个业务完成.

全代码如下：

@Slf4j@Servicepublic class AccountTCCServiceImpl implements AccountTCCService {    @Autowired    private AccountMapper accountMapper;    @Autowired    private AccountFreezeMapper freezeMapper;    @Override    @Transactional    public void deduct(String userId, int money) {        //1.获取事务 id        String xid = RootContext.getXID();        //a. 业务悬挂问题处理：判断 freeze 中是否有冻结记录，如果有，一定是 cancel 执行过，要拒绝业务        AccountFreeze oldFreeze = freezeMapper.selectById(xid);        if(oldFreeze != null) {            return;        }        //2.扣减可用余额        accountMapper.deduct(userId, money);        //3.增加冻结金额，并记录当前事务的状态        AccountFreeze freeze = new AccountFreeze();        freeze.setUserId(userId);        freeze.setXid(xid);        freeze.setFreezeMoney(money);        freeze.setState(AccountFreeze.State.TRY);        freezeMapper.insert(freeze);    }    @Override    public boolean confirm(BusinessActionContext ctx) {        //1.添加事务 id        String xid = RootContext.getXID();        //2.根据 id 删除冻结记录        int count = freezeMapper.deleteById(xid);        return count == 1;    }    @Override    public boolean cancel(BusinessActionContext ctx) {        //1.查询冻结记录        String xid = RootContext.getXID();        AccountFreeze freeze = freezeMapper.selectById(xid);        //a. 空回滚判断        if (freeze == null) {            //这里主要记录当前的 cancel 状态            freeze = new AccountFreeze();            //这里能拿到 userId 和 money 是因为在 AccountTCCService 接口中通过 BusinessActionContextParameter 注解注册了            String userId = ctx.getActionContext("userId").toString();            freeze.setUserId(userId);            freeze.setXid(xid);            freeze.setFreezeMoney(0);            freeze.setState(AccountFreeze.State.TRY);            freezeMapper.insert(freeze);        }        //b.幂等问题：第一次超时了，进行空回滚，第二次又超时了，freeze 不为空，就会进行恢复金额逻辑(这就出问题了).        if(freeze.getState() == AccountFreeze.State.CANCEL) {            //已经处理过依次 cancel 了，无需重复处理            return true;        }        //2.恢复可用余额        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());        //3.清理冻结余额，状态修改为 cancel        freeze.setFreezeMoney(0);        freeze.setState(AccountFreeze.State.CANCEL);        int count = freezeMapper.updateById(freeze);        return count == 1;    }}