深入了解分布式事务组件 Seata （一）

分布式事务的问题，在微服务架构中一直是难题。单体应用实现本地事务即可，到了分布式环境，情况就变得复杂。一个请求可能涉及多个服务，上下游存在依赖关系，其中的一环失败，需要将整个事务回滚。笔者在去年上半年开源过一款微服务的分布式事务组件： lottor ，基于可靠消息的柔性分布式事务实现方案。引入的 Lottor 客户端使用比较复杂，具有业务侵入性。推广使用的效果并不是很好。阿里在今年年初开源了 Seata（原名 fescar），引起了强烈的反响。笔者最近也在考虑改进 Lottor，借学习实践 Seata 的机会，和大家分享一下。

几款开源的分布式事务组件

既有的分布式事务解决方案按照对业务侵入性分为两类，即：对业务无侵入的和对业务有侵入的。

业务无侵入的方案

既有的主流分布式事务解决方案中，对业务无侵入的只有基于 XA 的方案（注：问题中提到的 JTA 是 XA 方案的 Java 版本），但应用 XA 方案存在 3 个方面的问题：

1. 要求数据库提供对 XA 的支持。如果遇到不支持 XA（或支持得不好，比如 MySQL 5.7 以前的版本）的数据库，则不能使用。

2. 受协议本身的约束，事务资源（数据记录、数据库连接）的锁定周期长。长周期的资源锁定从业务层面来看，往往是不必要的，而因为事务资源的管理器是数据库本身，应用层无法插手。这样形成的局面就是，基于 XA 的应用往往性能会比较差，而且很难优化。

3. 已经落地的基于 XA 的分布式解决方案，都依托于重量级的应用服务器（Tuxedo/WebLogic/WebSphere 等)，这是不适用于微服务架构的。

侵入业务的方案

实际上，最初分布式事务只有 XA 这个唯一方案。XA 是完备的，但在实践过程中，由于种种原因（包含但不限于上面提到的3 点）往往不得不放弃，转而从业务层面着手来解决分布式事务问题。比如：

• 基于可靠消息的最终一致性方案
• TCC
• Saga

都属于这一类。这些方案的具体机制在这里不做展开，网上这方面的论述文章非常多。总之，这些方案都要求在应用的业务层面把分布式事务技术约束考虑到设计中，通常每一个服务都需要设计实现正向和反向的幂等接口。这样的设计约束，往往会导致很高的研发和维护成本。

不可否认，侵入业务的分布式事务方案都经过大量实践验证，能有效解决问题，在各行种业的业务应用系统中起着重要作用。但回到原点来思考，这些方案的采用实际上都是迫于无奈。

Seata 介绍

Seata 是一款开源的分布式事务解决方案，提供高性能和简单易用的分布式事务服务。

包括了集团的 TXC（云版本叫 GTS）和蚂蚁金服的 TCC 两种模式，目前 Github 上的 star 数已经超过一万，算是目前唯一有大厂背书的分布式事务解决方案。

TXC 在 Seata 中又叫 AT 模式，意为补偿方法是框架自动生成的，对用户完全屏蔽，用户可以向使用本地事务那样使用分布式事务，缺点是仅支持关系型数据库（目前支持 MySQL），引入 Seata AT 的服务需要本地建表存储 rollback_info，隔离级别默认 RU 适用场景有限。

TCC 不算是新概念，很早就有了，用户通过定义 try/confirm/cancel 三个方法在应用层面模拟两阶段提交，区别在于 TCC 中 try 方法也需要操作数据库进行资源锁定，后续两个补偿方法由框架自动调用，分别进行资源提交和回滚，这点同单纯的存储层 2PC 不太一样。蚂蚁金服向 Seata 贡献了自己的 TCC 实现，据说已经演化了十多年，大量应用在在金融、交易、仓储等领域。

本文目前重点关注 Seata 中的 AT 模式。

Seata 组成

Seata 设计上将整体分成三个大模块，即 TM、RM、TC，具体解释如下：

• TM(Transaction Manager)：全局事务管理器，控制全局事务边界，负责全局事务开启、全局提交、全局回滚。

• RM(Resource Manager)：资源管理器，控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

• TC(Transaction Coordinator)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。

Seata AT 模式是基于两阶段提交模式设计的，以高效且对业务零侵入的方式，解决微服务场景下面临的分布式事务问题。

AT 模式的架构与实现原理介绍

分布式事务是一个全局事务，由多个分支事务组成，Seata AT 模式具体包括如下两个阶段：

• 阶段1：分支（本地）事务执行。将一个本地事务做为一个分布式事务分支，所以若干个分布在不同微服务中的本地事务共同组成了一个全局事务，结构如下。

• 阶段2：分支事务提交或回滚。阶段2完成的是全局事物的最终提交或回滚，当全局事务中所有分支事务全部完成并且都执行成功，这时TM会发起全局事务提交，TC收到全全局事务提交消息后，会通知各分支事务进行提交；同理，当全局事务中所有分支事务全部完成并且某个分支事务失败了，TM会通知TC协调全局事务回滚，进而TC通知各分支事务进行回滚。

在业务应用启动过程中，由于引入了 Seata 客户端，RmRpcClient会随应用一起启动，该RmRpcClient采用Netty实现，可以接收TC消息和向TC发送消息，因此RmRpcClient是与TC收发消息的关键模块。

Seata 实现分布式事务的一般过程如下：

• TM 通知 TC 开始一个新的全局事务。TC 生成了一个代表全局事务的 XID。
• XID 通过微服务的调用链传播下去。
• RM将本地事务注册为XID到TC的相应全局事务的分支。
• TM 通知 TC 提交或者回滚 XID 对应的全局事务
• TC 驱动 XID 的对应全局事务下的所有分支事务以完成分支提交或回滚。

Seata AT 模式使用入门

示例使用 seata-samples 中的 Seata-JPA 项目。

涉及到的几个服务如下所示：

客户端发起业务服务，Business 调用 Storage 锁定库存、Order 生成订单。Order 调用 Account 扣减余额。各个服务对应的角色已经在上图标注。

启动 TC 服务

首先，我们启动 Seata-Server，即 TC。下载 Seata-Server 的发行包。执行如下命令即可启动服务器。

sh distribution/bin/seata-server.sh -p 8091 -h 127.0.0.1 -m file

新建数据库表

执行几个服务涉及到的数据库表：

每个服务都有对应的业务表和 undo_log 表。

CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

在事务链涉及的服务的数据库中新建 undo_log 表用来存储 UndoLog 信息，用于二阶段回滚操作，表中包含 xid、branchId、rollback_info 等关键字段信息。

增加全局事务注解

@GlobalTransactional
public void purchase(String userId, String commodityCode, int orderCount) {
    storageFeignClient.deduct(commodityCode, orderCount);

    orderFeignClient.create(userId, commodityCode, orderCount);
}

依赖 Seata 的客户端 SDK，然后在整个分布式事务发起方的业务方法上增加 @GlobalTransactional 注解。

配置代理数据源

Seata 中主要针对 java.sql 包下的 DataSource、Connection、Statement、PreparedStatement 四个接口进行了再包装，包装类分别为 DataSourceProxy、ConnectionProxy、StatementProxy、PreparedStatementProxy，很好一一对印，其功能是在 SQL 语句执行前后、事务 commit 或者 rollbakc 前后进行一些与 Seata 分布式事务相关的操作，例如分支注册、状态回报、全局锁查询、快照存储、反向 SQL 生成等。

@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties(prefix = "spring.datasource")
    public DruidDataSource druidDataSource() {
        return new DruidDataSource();
    }

    @Primary
    @Bean("dataSource")
    public DataSource dataSource(DruidDataSource druidDataSource) {
        return new DataSourceProxy(druidDataSource);
    }
}

需要将 DataSourceProxy 设置为主数据源，否则事务无法回滚。

验证

业务服务中提供了两个接口，一个正常提交，另一个回滚，执行之后查看结果。

GET http://127.0.0.1:8084/purchase/commit
Accept: application/json

###
GET http://127.0.0.1:8084/purchase/rollback
Accept: application/json

大家可以自行验证一下结果。