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

Hollis

共 8821字,需浏览 18分钟

 ·

2021-06-23 21:29

分布式事务的实现方式中,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做了一些优化,包括第二阶段异步提交和同库模式,性能提升很明显。

有道无术,术可成;有术无道,止于术

欢迎大家关注Java之道公众号


好文章,我在看❤️

浏览 54
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报