分布式事务,阿里为什么钟爱TCC
共 8821字,需浏览 18分钟
·
2021-06-23 21:29
之前写过一篇文章说了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做了一些优化,包括第二阶段异步提交和同库模式,性能提升很明显。
有道无术,术可成;有术无道,止于术
欢迎大家关注Java之道公众号
好文章,我在看❤️