分布式事务，阿里为什么钟爱TCC

分布式事务的实现方式中，TCC是比较知名的模式。但是我一直不喜欢这种模式，原因是这种模式有很多问题要考虑。

之前写过一篇文章说了TCC的很多缺点，后来我把文章删了，原因是一位阿里大佬加我好友并指正了我的观点。

太感谢了！

1 TCC概要

简单来讲，TCC模式就是将整个事务分成两个阶段来提交，try阶段进行预留资源，如果所有分支都预留成功，则进入commit阶段提交所有分支事务，否则执行cancel取消所有分支事务。

以电商系统为例，假如有订单、库存和账户3个服务，客户购买一件商品，订单服务增加订单，库存服务扣减库存，账户服务扣减金额，这三个操作必须是原子性的，要么全部成功，要么全部失败。

try阶段

如下图：

订单服务增加一个订单，库存服务冻结订单上的库存，账户服务冻结订单上的金额。

订单、库存和账户这三个服务作为整个分布式事务的分支事务，在try阶段都是要提交本地事务的。上面库存和账户说的冻结，就是说这个订单对应的库存和金额已经不能再被其他事务使用了，所以必须提交本地事务。

但这个提交并不是真正的提交全局事务，而是把资源转到中间态，这个中间态需要在try方法的业务代码中实现，比如账户扣除的金额可以先存放到一个中间账户。

如果try阶段不提交本地事务会有什么问题呢？有可能其他事务在try阶段发现用户账户里面的金额还够，但是commit的时候发现金额不够了，commit阶段扣款只能失败，这时其他两个分支事务提交成功而账户服务的分支事务提交失败，最终数据就不一致了。

commit阶段

如下图：

commit阶段，数据从中间态转入终态，比如订单金额从中间账户转到最终账户。

cancel阶段跟commit阶段类似，比如订单金额从中间账户退回到客户账户。

2 问题代码

下面这段代码也可以理解为TCC，是在try阶段hold住了connection，不提交分支事务，到commit阶段再提交分支事务。代码如下：我们以扣减账户为例，首先定义2个变量来hold住connection：

private Map<String, Statement> statementMap = new ConcurrentHashMap<>(100);
private Map<String, Connection> connectionMap = new ConcurrentHashMap<>(100);

try方法代码如下：

public boolean try(String xid, Long userId, BigDecimal payAmount) {LOGGER.info("decrease, xid:{}", xid);LOGGER.info("------->尝试扣减账户开始account");try {//尝试扣减账户金额,事务不提交Connection connection = hikariDataSource.getConnection();connection.setAutoCommit(false);String sql = "UPDATE account SET balance = balance - ?,used = used + ? where user_id = ?";PreparedStatement stmt = connection.prepareStatement(sql);stmt.setBigDecimal(1, payAmount);stmt.setBigDecimal(2, payAmount);stmt.setLong(3, userId);stmt.executeUpdate();statementMap.put(xid, stmt);connectionMap.put(xid, connection);} catch (Exception e) {LOGGER.error("decrease parepare failure:", e);return false;}LOGGER.info("------->尝试扣减账户结束account");return true;
}

commit方法代码如下：

public boolean commit(BusinessActionContext actionContext){String xid = actionContext.getXid();PreparedStatement statement = (PreparedStatement) statementMap.get(xid);Connection connection = connectionMap.get(xid);try {if (null != connection){connection.commit();}} catch (SQLException e) {LOGGER.error("扣减账户失败:", e);return false;}finally {try {statementMap.remove(xid);connectionMap.remove(xid);if (null != statement){statement.close();}if (null != connection){connection.close();}} catch (SQLException e) {LOGGER.error("扣减账户提交事务后关闭连接池失败:", e);}}return true;
}

cancel方法代码如下：

public boolean rollback(BusinessActionContext actionContext){String xid = actionContext.getXid();PreparedStatement statement = (PreparedStatement) statementMap.get(xid);Connection connection = connectionMap.get(xid);try {connection.rollback();} catch (SQLException e) {return false;}finally {try {if (null != statement){statement.close();}if (null != connection){connection.close();}statementMap.remove(xid);connectionMap.remove(xid);} catch (SQLException e) {LOGGER.error("扣减账户回滚事务后关闭连接池失败:", e);}}return true;
}

这段代码是问题代码，不能用，不能用，不能用

这个代码存在两个问题：

2.1 阻塞等待

如果当前事务不提交，比如账户服务，那就相当于是锁定了资源，后面的事务只能等待资源释放。

2.2 服务集群

以订单服务为例，假如订单服务是一个3个机器的集群，如下图：

协调节点使用注册中心客户端来调用订单服务，如果try请求发送到了订单服务1，而commit请求发送到了订单服务2，那订单服务2上的connectionMap里不会有xid=123这个connection，只能提交失败。

3 TCC存在的问题

上面的问题代码就是给大家一个思路，如果真要hold住connection，也算是实现了TCC的思想，但是在系统中，我们是不可能这样做的，所以把它叫做问题代码。

3.1 空回滚

如下图，订单服务1节点故障，如果不考虑重试，try方法失败：

try虽然失败了，但是全局事务已经开启，框架必须要把这个全局事务推向结束状态，这就不得不调用订单服务cancel方法进行回滚，结果订单服务空跑了一次cancel方法。

解决这个问题，可以记录一张事务控制表，保存全局事务xid和分支事务branchId，try阶段会插入一条记录，表示try阶段执行了。cancel方法读取该记录，如果记录存在，正常回滚；如果该记录不存在，那就是空回滚。

3.2 幂等

幂等是指在commit/cancel阶段，因为TC没有收到分支事务的响应，需要进行重试，这就要分支事务支持幂等。以订单服务为例。如下图：

要支持幂等，可以记录一张事务控制表，保存全局事务xid和分支事务branchId，以及分支事务状态，在第二阶段commit/cancel之前先检查分支事务状态是否已经是终态，如果不是，再执行第二阶段的逻辑。

3.3 悬挂

悬挂是指事务的cancel方法比try方法先执行。上面讲了seata的使用过程中会发生空回滚，如果发生了空回滚，执行了cancel方法后全局事务结束了，但是因为网络问题，订单服务又收到了try请求，执行try方法后预留资源成功，这些资源最终不能释放了。

解决这个问题的方法就是在cancel方法中记录xid对应的分支事务回滚记录，try阶段执行的时候先判断分支事务是否已经回滚，如果存在回滚记录，则直接退出。

3.4 业务代码侵入

TCC的try/commit/cancel，对业务代码都有侵入，而且每个方法都是一个本地事务。再加上需要考虑幂等、空回滚、悬挂等，代码侵入会更高。

4.TCC优势

这里以seata实现的四种模式来比较，包括XA、SAGA、TCC、AT。

效率

使用TCC模式时，在try阶段就提交了本地事务，并不会锁定资源，所以没有其他额外的性能开销。相比之下，来看其他几种模式：

AT模式，需要记录undolog，性能损耗很大。
XA模式，执行xa start | sql | xa end之后，执行commit/rollback之前，会锁定资源，后面的事务需要等待。

saga模式

更适合长流程的业务场景。

5.性能优化

参考^[1]

5.1 异步提交

优化思路是try阶段成功后，不立即执行confirm/cancel阶段，而是等系统空闲的时候异步执行。如下图：

这样在try阶段结束后，就认为全局事务结束了，可以定时(比如10分钟)来异步执行第二阶段，性能大幅提升。

当然，带来的一点问题就是如果全局事务回滚，会有短暂的数据不一致。比如扣款的场景，定时10分钟执行一次异步任务，如果第二阶段是cancel，那客户会在这10分钟内不能使用这笔金额。

这个异步执行的时间也可以根据业务来决定，比如不需要及时从中间账户转移到最终账户的场景可以设置更长。

5.2 同库模式

首先回顾一下TCC中各个角色：

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

先看一下优化之前的通信模型，如下图：

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

优化之后的模型如下图：

TM开启全局事务时，不再需要向TC注册分支事务，而是把分支事务状态保存在了本地。TM向TC发送提交或回滚消息时，TC保存全局事务的状态。而RM则启动异步线程检测本地记录的未提交分支事务，向TC发送RPC消息获取整体事务状态，以决定是提交还是回滚本地事务。可见，优化后的模型，RPC次数减少了50%，性能大幅提升。

6.总结

TCC的问题确实不少，但是除了侵入业务代码这一个问题，其他问题都有对应的解决方案。

阿里针对TCC做了一些优化，包括第二阶段异步提交和同库模式，性能提升很明显。

参考资料

[1]

参考: https://tech.antfin.com/community/live/462/data/736