Seata XA模式实战：从分布式事务原理到订单库存强一致落地

1. 为什么还要聊XA：分布式事务的最后一公里

先从一个我上个月刚处理的线上事故说起。某个核心订单服务在压测环境下，库存扣减成功但订单创建失败，一查日志，发现是库存服务把数据回滚了，订单服务自己提交了事务，两边数据直接不一致。这种问题在单体应用里根本不存在，但一旦拆成微服务、拆了库，分布式事务就成了绕不过去的坎。

SEATA分布式事务是目前国内用得最多的开源分布式事务方案，它本身提供了AT、TCC、SAGA、XA四种模式。这里面的XA模式，本质上不是Seata创新的东西，而是把数据库标准里早就定义的XA协议接进了Seata框架，让Seata的TM、TC、RM三个核心角色配合数据库自己的事务管理器，完成跨服务的强一致性事务控制。

这篇文章我想把XA模式从原理到实操完整讲一遍。内容适合这几类人看：正在做订单、库存、支付这类强一致场景的后端开发，准备Seata分布式事务面试题的技术候选人，以及已经在用AT模式但想搞清楚什么时候该切XA模式的架构师。

先给一个结论：如果在面试里被问到“Seata的几种模式怎么选”，XA模式就是那个“性能差但一致性最强、实现最简单”的选项。它不适合所有场景，但在某些必须保证强一致的业务里，它是性价比最高的方案，没有之一。

2. Seata与XA模式整体设计思路拆解

2.1 分布式事务到底在解决什么问题

在拆Seata之前，先把问题定义清楚。分布式事务的核心场景，就是一次业务操作涉及多个独立的资源，比如订单库、库存库、账户库，它们分布在不同的数据库实例甚至不同的物理机上。单体时代，一个数据库事务就能搞定；微服务加分库之后，每个服务有自己独立的本地事务，但跨服务之间没有统一的事务边界。

这个时候会出现什么情况？订单创建成功了，库存扣减失败回滚了，用户拿着一笔付了钱但没货的订单来找客服。或者库存扣了，订单没创建成功，库存无声无息地消失了。无论是哪种，都属于数据不一致问题，也就是分布式事务要解决的。

业界解决这个问题的思路大致分两类：一类是强一致方案，代表就是XA两阶段提交，所有参与方要么全成功要么全失败；另一类是最终一致方案，代表是本地消息表、事务消息、TCC、SAGA，允许短暂的不一致，通过补偿机制最终对齐。Seata牛逼的地方在于，它把这两类方案都收进了同一个框架，开发者只需要选模式，然后在一个注解上改个值，就能切换事务策略。

2.2 Seata的三个角色：TM、TC、RM

Seata分布式事务原理里最关键的就是理解三个角色：TM（Transaction Manager，事务管理器）、TC（Transaction Coordinator，事务协调器）、RM（Resource Manager，资源管理器）。很多面试题直接考这个，但光背概念没用，得知道它们在一次分布式事务里分别干了什么。

拿一个订单创建流程举例：用户下单，事务发起方是订单服务，这个订单服务就是TM，它负责向TC发起全局事务的开启、提交或回滚指令。TC是独立部署的Seata Server，它负责记录全局事务的状态，协调所有参与者。订单、库存、账户三个服务各自内部都有RM，RM负责管理分支事务，也就是本地事务，以及向TC注册分支、上报状态。

整个流程是这样的：TM告诉TC“我要开一个全局事务”，TC生成一个全局事务ID（XID）；XID通过调用链传递到库存服务和账户服务；每个服务的RM收到XID后，执行自己的本地事务，然后向TC注册分支事务；业务全部执行完，TM向TC说“可以提交了”，TC再通知所有RM提交各自的分支事务，或者某个环节出错了，TC通知所有RM回滚。这个模型不只是XA在用，AT模式也完全复用这一套架构，区别只在于RM底层的实现机制不同。

2.3 AT模式和XA模式的差异与选型逻辑

既然Seata的四种模式里，AT模式在框架里是出镜率最高的，为什么还要单独讲XA？因为有相当一部分场景，AT模式并不能胜任。

AT模式的核心思路是“业务无侵入”。它通过拦截SQL，在业务数据变更的同时记录undo_log回滚日志。执行阶段，AT模式只是自动把每个本地事务提交掉；如果后续某个分支失败需要回滚，TC通知RM根据undo_log去反向补偿，把数据恢复成原样。这种方案性能好，业务代码不用改SQL，非常适合大多数互联网业务。

但AT模式有三个明显的弱点。第一，它只能保证最终一致性，回滚是补偿式的，数据在中间状态是可见的，强一致场景下可能有问题；第二，undo_log补偿不是万能的，如果回滚期间有别的请求修改了同一行数据，就会产生脏写，需要额外的全局锁保护；第三，AT模式依赖Seata框架对SQL的解析和拦截，在一些复杂的SQL写法下会出现解析问题。

XA模式走的是另一个极端：事务执行期间，所有参与方的资源直接被数据库锁住，要么全部提交，要么全部回滚，中间状态对业务不可见，是真正的强一致。代价就是锁的持有时间被拉长，并发能力被削弱。所以选型逻辑很清晰：对一致性要求极高、并发量不大、数据库本身支持XA协议的核心链路，用XA；对一致性要求不极致、追求吞吐量的场景，用AT。

3. 核心细节解析与实操要点

3.1 XA协议的两阶段提交到底怎么运作

XA模式的核心就是两阶段提交，这是数据库领域的老协议了，1991年左右就进了X/Open标准。我在实际排查问题的时候发现，不少人知道“两阶段”这个名词，但说不清楚两个阶段到底在做什么、各自有什么风险。

第一阶段叫准备阶段，Second Phase Commit的前奏。事务协调者（也就是Seata里的TC）向所有参与者发出prepare请求。每个参与者收到请求后，执行事务操作到一半，但不提交，而是把事务状态改为“可提交”，然后向协调者回复“我准备好了”。这个状态的学名叫“就绪状态”，数据库会把这个事务的修改写入事务日志，并且持有相关行或表的锁。

第二阶段是提交阶段。协调者收到所有参与者的“准备好了”回复后，如果全部成功，就向所有参与者广播commit命令；如果任何一个参与者回复prepare失败或者超时，协调者就广播rollback命令。参与者收到命令后执行真正的提交或回滚，释放锁。

这个机制最致命的问题，其实在第一阶段没有“全票通过”这种中间路径。只要协调者在第二阶段发出commit命令之后挂了，而某个参与者没收到commit，它就会一直卡在就绪状态，锁一直不释放，直到协调者恢复并再次下发指令。这就是XA模式长期被诟病“阻塞式协议”的原因。Seata在这一层并没有做颠覆式改造，它的价值是把这套标准协议接入框架，让开发者不需要手动编写与数据库XA接口交互的代码。

3.2 分支事务与全局事务的映射关系

在Seata里，XA模式执行时，一次全局事务会被拆成一个或多个分支事务，这个分支事务和数据库原生XA事务是一一对应的。我一开始学Seata的时候，经常把“全局事务”“分支事务”“本地事务”这三层搞混，这里用下单过程把三层关系说透。

全局事务指的是整个业务链路，从TM发起开启到最终提交或回滚，对应Seata框架里GlobalTransaction这个概念；分支事务指单个服务内部的资源操作事务，对应Seata框架里的BranchTransaction；本地事务指分支事务内部的数据库本地事务，对应Spring框架里的@Transactional。XA模式下，一个分支事务内部，Seata会让RM把本地事务和一个XA事务绑定，这个XA事务的XID包含了Seata的全局XID和分支ID。

具体执行到RM层，Seata会向数据库发起XA START命令，开启一个XA事务分支，然后执行本地SQL操作，再发起XA END命令，最后发起XA PREPARE进入就绪状态。这就是第一阶段。第二阶段由TC统一协调，RM收到提交或回滚指令后，执行XA COMMIT或XA ROLLBACK。整个过程中，TM、TC、RM三层各司其职，没有谁替谁干活。

3.3 XA模式为什么“简单”：DataSource做的事情

对比AT模式和TCC模式，XA模式最大的优势体现在代码层面。AT模式虽然业务无侵入，但需要建立undo_log表、配置全局锁相关参数，对SQL解析也依赖框架版本；TCC模式更麻烦，每个接口得手写try、confirm、cancel三个方法，业务侵入非常明显。XA模式则几乎做到了“零业务侵入”，Seata帮我们把底层的XA协议封装在了一个代理数据源里。

这里的关键是无处不在的DataSource。正常情况下，Spring项目里配置的数据源是HikariCP之类的连接池，业务代码通过JdbcTemplate或MyBatis从数据源拿连接。Seata的XA模式把这里替换成了一个代理数据源，它内部的连接在执行SQL前会自动被包装成XAConnection。业务代码该怎么写还怎么写，MyBatis的Mapper、Mapper.xml都不用动，事务管理器里也只需要切到Seata提供的DataSourceTransactionManager，剩下的事情全部交给框架。

我在实操中对比过，同一个订单服务，从AT模式切换到XA模式，需要改动的地方只有两个：配置文件和注册Seata数据源代理的Bean。业务层的@Transactional、@GlobalTransactional注解一概不动。这种“配置级”切换带来的体验，对日常迭代维护的项目来说真的太重要了。

4. 实操过程：订单与库存场景的XA模式完整落地

4.1 环境准备：Seata Server、数据库和依赖版本

我在本机实验的环境是这样的，可以作为一个最小可行配置直接参考：操作系统是Linux虚拟机，Seata Server版本用的1.6.1，数据库是MySQL 8.0，存储引擎InnoDB，连接池用的HikariCP。Java版本用8，Spring Boot用的是2.5.6，mybatis-spring-boot-starter版本2.2.0。

Seata Server部署不算复杂，下载seata-server-1.6.1.tar.gz后解压，修改conf目录下的application.yml，把store模式改成db，配置好数据库连接，这样全局事务的会话信息就会持久化到数据库，避免Server重启丢状态。启动命令是sh seata-server.sh -p 8091 -m db，端口默认8091。这里有一点需要注意：Seata Server和业务服务的配置要保持一致，特别是事务组名和注册中心地址。

MySQL这边，必须确认引擎是InnoDB，MyISAM不支持XA。另外版本也有讲究，MySQL 5.7和8.0都支持XA语法，但8.0在XA事务的持久化表现上更好。

4.2 引入依赖与核心配置

开始写代码之前，先把Maven依赖加好。业务服务除了自己原来的依赖之外，需要额外引入两样东西：seata-spring-boot-starter，以及seata的XA模式相关模块。

xml复制<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2021.0.4.0</version>
</dependency>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>1.6.1</version>
</dependency>

如果你用的是Spring Cloud Alibaba，直接引入spring-cloud-starter-alibaba-seata就够了，它内部会把Seata的starter一并带进来。接着在application.yml里配置Seata的客户端信息：

yaml复制seata:
  enabled: true
  application-id: order-service
  tx-service-group: my_test_tx_group
  enable-auto-data-source-proxy: true
  data-source-proxy-mode: XA
  service:
    vgroup-mapping:
      my_test_tx_group: default
    grouplist:
      default: 127.0.0.1:8091

这段配置里有几个参数非常关键。data-source-proxy-mode设为XA，是告诉Seata我们这次启用XA模式，不是AT模式，这个参数容易被忽略，但切换模式全靠它。tx-service-group是事务分组名，它必须和Seata Server配置的service.vgroupMapping保持一致。application-id则是服务在Seata控制台显示的标识，最好改成实际业务名称，否则排查分布式事务时，看不到是哪个服务注册的分支。

4.3 配置数据源代理，让XA模式自动生效

配置完application.yml，还差一个关键Bean。XA模式是通过代理DataSource来实现的，所以必须注册Seata提供的DataSourceProxy。如果不注册，Spring容器里的数据源还是原装的HikariCP，Seata没法在执行SQL时插入XA相关的逻辑。

java复制@Configuration
public class SeataDataSourceConfig {

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

    @Bean
    public DataSourceProxy dataSourceProxy(DataSource orderDataSource) {
        return new DataSourceProxy(orderDataSource);
    }

    @Bean
    public DataSourceTransactionManager transactionManager(DataSourceProxy dataSourceProxy) {
        return new DataSourceTransactionManager(dataSourceProxy);
    }

    @Bean
    public SqlSessionFactory sqlSessionFactory(DataSourceProxy dataSourceProxy) throws Exception {
        SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean();
        factoryBean.setDataSource(dataSourceProxy);
        return factoryBean.getObject();
    }
}

需要特别强调的是，MyBatis的SqlSessionFactory必须使用被代理过的DataSource，否则MyBatis拿到的连接还是普通连接，XA分支根本不会被触发。这个坑我不只一次见人踩到：配置了data-source-proxy-mode: XA，但SqlSessionFactory没有使用代理DataSource，结果执行期毫无XA效果，数据照样不一致。注册代理数据源这一点，在XA模式的落地清单里排在第一位。

4.4 业务代码：一个注解搞定全局事务

业务代码的核心是TM发起方加@GlobalTransactional注解。这个注解是Seata框架穿透全局事务的入口，它会拦截方法执行，在方法开始时向TC注册全局事务，方法结束时根据执行状态向TC提交或回滚。

java复制@Service
public class OrderServiceImpl implements OrderService {

    @Resource
    private OrderMapper orderMapper;
    @Resource
    private ProductServiceClient productServiceClient;

    @Override
    @GlobalTransactional(name = "create-order-xa", rollbackFor = Exception.class)
    public boolean createOrder(OrderRequest request) {
        Order order = new Order();
        order.setProductId(request.getProductId());
        order.setQuantity(request.getQuantity());
        order.setStatus(1);
        orderMapper.insert(order);

        boolean deducted = productServiceClient.deductStock(request.getProductId(), request.getQuantity());
        if (!deducted) {
            throw new RuntimeException("库存不足，订单创建失败");
        }
        return true;
    }
}

这里有个重要细节：@GlobalTransactional只会在TM发起方加，库存服务和账户服务内部的本地事务，只需要普通的@Transactional即可，它们的RM会通过调用链中传递的XID感知到自己是全局事务的一部分。XID的传递在Spring Cloud场景下是Seata框架的过滤器自动处理的，通过Seata的RootContext和Dubbo或Feign的拦截器把XID注入到RPC调用头里，下游服务自动取出并绑定。

4.5 库存服务侧的实现

库存服务侧的代码和订单服务几乎一样，唯一区别是它不需要@GlobalTransactional，只要在扣除库存的方法上加上普通的@Transactional。为什么？因为库存服务是被调用方，它不能自己去开启一个全局事务，否则两个服务各管各的全局XID，协调器就乱套了。

库存服务的DataSource也要替换成Seata的代理。建议把数据源配置类抽成一个公共模块，让订单、库存、账户三个服务复用，以免每个服务各写一遍踩坑。

java复制@Service
public class StockServiceImpl implements StockService {

    @Resource
    private StockMapper stockMapper;

    @Override
    @Transactional(rollbackFor = Exception.class)
    public boolean deductStock(Long productId, Integer quantity) {
        int updated = stockMapper.deductStock(productId, quantity);
        return updated > 0;
    }
}

对应的SQL很简单：

sql复制UPDATE stock SET available = available - #{quantity}
WHERE product_id = #{productId} AND available >= #{quantity}

4.6 验证结果：让库存扣减后强制抛异常

代码写完，最重要的验证环节来了。只测“正常下单成功”没意义，必须制造一个故障场景，验证回滚逻辑真正有效。我的测试方法是这样的：在订单服务创建订单成功后，库存服务扣除库存后，主动抛一个RuntimeException，模拟下游业务失败。

按照XA模式的预期，此时TM会收到异常，向TC发起全局回滚请求，TC再让订单服务RM回滚订单插入，让库存服务RM回滚库存扣减。执行完之后，两张表的数据都应该恢复到操作前的状态。

我特意在订单插入后、库存扣减后分别加了日志输出，观察执行顺序和最终结果。断点显示日志顺序依次是：订单插入成功、库存扣减成功、库存服务抛出异常、订单服务捕获异常、全局事务回滚完成。查询订单表，新插入的订单不存在；查询库存表，扣减的库存已经恢复原值。

这个结果完全符合预期。XA模式下，两个服务的数据要么同时提交，要么同时回滚，没有一个“中间状态”可以被其它线程读到。

4.7 从日志看懂XA执行链路

如果你在操作系统里打开Seata Server的日志，或者在业务服务里把Seata的日志级别调成debug，能看到一条清晰的执行链路。首先是TM发起全局事务，日志里出现Register global transaction xid = 192.168.1.100:8091:2121998900786549032；然后库存服务收到Feign调用，日志里出现Register branch success，这个分支事务的XID会带上分支ID；接着在prepare阶段，出现xa prepare；最后提交阶段，出现xa commit或xa rollback。

我在排障的时候，最常用的手段就是拿XID去Seata Server的日志里grep。比如下游扣库存成功但一直没提交，就可以去TC日志查这个XID对应分支的状态；如果分支状态一直停在PhaseOne_Done，说明prepare完成了但第二阶段还没下发，要么是TC和RM之间的通信断了，要么是TC挂了。

5. 常见问题与排查技巧实录

5.1 问题速查表：我踩过的XA模式大坑

XA模式虽然模型简单，但落地过程中坑不算少。下面这个表是我自己在项目中实地踩过、帮同事排查过的记录，整理成一个速查表，每一个都值得收藏。

5.2 连接池耗尽问题：XA模式最常见的“翻车点”

XA模式下最经典的问题，是连接池被占满之后服务直接雪崩。为什么会出现这个现象？因为XA事务从第一阶段prepare开始，到第二阶段commit或rollback结束，整个期间数据库连接一直被占用。在高并发场景下，如果每一个请求都调用了下游服务，下游服务的数据库连接池很快就满了，新的请求拿不到连接，全部进入等待队列。

我曾经在压测环境里用50个并发线程跑一个涉及三个服务的XA链路，压测开始后大约2分钟，库存服务的HikariCP连接池满了，大量请求超时。当时第一反应是数据库慢查询，看了一圈发现没有任何SQL是慢的，最后才反应过来是连接被XA事务长时间占用。

解决方案有几个层面。第一个层面，调大连接池的maximumPoolSize，但这不是无上限的，毕竟数据库本身的连接数有限；第二个层面，缩短事务边界，把耗时的外部调用尽量挪出@GlobalTransactional方法；第三个层面，降低并发度，或者考虑把强一致链路拆细一点，不要在同一个全局事务里塞太多分支。

5.3 XA模式性能调优：5个实战参数

既然XA模式的性能瓶颈在锁和连接占用，那优化方向就很明确。基于我自己的实测经验，以下5个参数的调整效果最明显。

事务超时时间要设置合理，Seata的@GlobalTransactional的timeoutMills默认是60000毫秒，如果业务执行时间不超过3秒，建议把超时时间缩到15000毫秒左右。这样一旦某条链路卡住，TC能更快地强制回滚，锁也会更早释放。

数据库端的innodb_lock_wait_timeout，默认50秒还是太长。我在XA模式下会把它调到5秒，让锁等待快速报错，避免线程池被长期占据。当然这个值要根据业务容忍度调整，不能一刀切。

连接池的minimumIdle和maximumPoolSize，对于XA分支比较多的服务，我建议minimumIdle=10、maximumPoolSize=40起步，具体看QPS估算。另外连接池的connectionTimeout要配得比全局事务超时时间短，否则会先在拿连接这一步等待很久。

Seata Server的线程池参数也可以调。如果压测发现TC的请求积压，可以在Server的application.yml里把执行线程池的核心线程数调大。默认值是50，我一般调到200，这个参数在高并发场景下提升很明显。

5.4 面试高频题速答：Seata分布式事务原理

既然热词里出现了“seata面试题”，这里按照面试官的提问逻辑，挑几个高频问题给出一套可以直接背下来的回答思路。但记住一点，背答案不如真正跑通一次上面的示例工程，理解会牢靠得多。

问题一：Seata的工作流程是什么？回答思路：先说三个角色TM、TC、RM的职责，再说一次分布式事务的完整生命周期：TM向TC申请全局事务得到XID；XID通过RPC传递给下游；RM执行本地事务并注册分支；TM发起全局提交或回滚；TC汇总分支状态后下发二阶段指令。

问题二：AT和XA有什么区别？回答思路：AT是补偿式、最终一致，业务侵入小，基于undo_log反向补偿，需要全局锁；XA是数据库原生协议、强一致，通过两阶段提交实现，事务期间锁持有时间长、并发低。

问题三：两阶段提交有什么缺点？回答思路：第一是同步阻塞，第一阶段所有参与资源锁定，第二阶段未下达前不释放；第二是协调者单点，协调者宕机可能造成全体阻塞；第三是数据不一致窗口，commit命令广播过程中，部分参与方收到而部分没收到，仍会出现不一致状态。

问题四：Seata的XA模式底层是怎么实现的？回答思路：Seata把数据源代理成DataSourceProxy，连接被包装成XAConnection；执行过程中自动下发XA START、XA END、XA PREPARE，第二阶段接收TC指令执行XA COMMIT或XA ROLLBACK。

问题五：什么场景适合用XA模式？回答思路：并发量不大、必须强一致的核心链路，比如订单支付、资金转账、库存台账类业务。并发高、可以容忍短暂不一致的场景，优先考虑AT或TCC。

5.5 与AT模式的最终选型建议

最后再给一个务实的选型建议。SEATA分布式事务的XA模式，不是用来替代AT模式的，它是AT模式的一个补充，给那些对一致性要求极端的场景兜底。

我在实际项目中总结的判断标准是：如果业务操作中，任何一个分支失败后，其他分支的数据暴露给用户会造成资损或业务紊乱，那就必须用XA。比如转账场景，扣款成功、入账失败，账户余额和流水对不上，用户立刻会感知到，这种就不能用最终一致方案。反过来，如果业务可以接受短暂的“数据延迟”，比如订单超时关闭、优惠券异步发放，用AT模式完全没问题，吞吐量还高。

XA模式在Seata里的定位就是“简单、可靠、性能换一致性”。它不是银弹，但当你需要强一致的时候，它是最好的银弹之一。对一个后端开发者来说，能分清这四种模式各自的边界，再配合跑通一次XA的示例，就足以应付大多数架构讨论了。