搞分布式事务，尤其是刚接触 Seata 的时候，不少人第一眼看到的就是 AT 模式，因为资料多、案例也多。但真到了金融、订单、库存这类对数据一致性要求极高的场景，我反而会建议你先看看 XA 模式。这个模式在 Seata 里常被说成是“天生强一致”，但实际用起来坑也不少。这篇文章就围绕 Seata 的 XA 模式，从原理到实战，把关键细节一次讲透。
1. 分布式事务到底在解决什么问题
1.1 本地事务为什么不够用
先回到最熟悉的场景。一个单体应用，一个数据库，扣库存、扣余额、生成订单，这组操作全在同一个数据库连接里执行，用@Transactional就能搞定。你只要保证 ACID 里的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），数据库自己就会帮你把事务管好。commit 就全生效，rollback 就全撤掉。
但一旦业务拆分成了微服务，订单服务、库存服务、账户服务各管一个库，情况就完全变了。你在订单服务里下单成功，调用库存服务扣减库存也成功，结果账户服务扣款失败，这时候你面对的已经不是一个数据库事务能覆盖的范围，而是跨服务、跨库的分布式事务问题。传统意义上的 ACID 在分布式环境下很难完全满足，所以我们退而求其次，走 CAP 理论和 BASE 原则，保证最终一致性。
1.2 Seata 的定位：分布式事务中间件
Seata（Simple Extensible Autonomous Transaction Architecture）要干的事，就是在微服务架构下，把原本分散在各数据库、各服务里的操作，重新纳入一个全局事务的管理范围。它的整体思路很简单：一个全局事务由若干分支事务组成，分支事务就是各个服务里的本地事务，Seata 负责协调这些分支事务要么全部成功，要么全部回滚。
Seata 里有三个核心角色：TC（Transaction Coordinator，事务协调器）、TM（Transaction Manager，事务管理器）、RM（Resource Manager，资源管理器）。TC 是独立部署的服务端，负责维护全局事务和分支事务的状态；TM 在应用侧，负责开启、提交或回滚全局事务；RM 也是应用侧的角色，负责管理分支事务，向 TC 注册分支，并执行实际的分支提交或回滚。整个过程简单说就是：TM 告诉 TC“我开始一个全局事务了”，各个 RM 在执行完本地操作后向 TC 注册分支，最后 TM 再向 TC 发指令，决定是全局提交还是全局回滚。
1.3 强一致和最终一致怎么选
Seata 之所以提供了多种事务模式，是因为分布式事务本身没有银弹。XA 这种基于数据库层面实现的模式，追求的是强一致，事务提交前所有参与者都处于可回滚状态，一旦提交，数据立刻在所有库上生效。AT 模式则偏向最终一致，通过拦截 SQL、生成 undo log 的方式，先完成本地提交，再在全局提交阶段做一些补偿。实际业务里怎么选，核心还是要看一致性要求高不高、并发大不大、能不能接受短时间的中间状态。
2. XA 模式的核心原理拆解
2.1 XA 协议到底是什么
XA 是一个分布式事务处理的标准协议，规范了全局事务管理器（Transaction Manager，TM）和各个资源管理器（Resource Manager，RM）之间的交互接口。这个标准最早由 X/Open 组织提出，后来被几乎所有主流关系型数据库采纳，MySQL、Oracle、PostgreSQL 都能原生支持 XA。
XA 的事务流程是两阶段提交（Two-Phase Commit，2PC）。第一阶段叫准备阶段（Prepare），事务协调者向所有参与者发送 prepare 请求，各参与者执行事务操作，但不真正提交，只把事务状态锁定在可提交状态，并返回 ready 或 abort。第二阶段叫提交阶段（Commit），协调者如果收到所有参与者都 ready，就发送 commit 命令，各参与者完成最终提交；只要有任何一个参与者返回 abort，协调者就发送 rollback，所有参与者撤销第一阶段的操作。
这个设计的巧妙之处在于，第一阶段把所有不确定性都暴露出来了。任何一个参与者执行失败，全局事务都有机会在提交前被终止，不会出现两个库一个提交了一个没提交的情况。
2.2 Seata 对 XA 模式的封装
Seata 的 XA 模式并没有重新造轮子，而是把原生 XA 协议纳入了自己的全局事务框架。你可以理解为 Seata 在应用侧实现了一个合规的 RM，应用通过 Seata 提供的数据源代理来使用数据库连接，Seata 在背后帮你发起 XA 的 begin、prepare、commit、rollback 操作。
关键点在于，XA 的职责分工和 Seata 的三角色天然契合。Seata 的 TC 充当全局事务协调者，维护全局事务的状态；应用里的 TM 负责和业务代码交互，标注全局事务边界；Seata 内置的 RM 则负责把业务 SQL 包装在 XA 事务里，向 TC 注册分支事务，并执行数据库底层的 prepare/commit/rollback。业务代码并不直接对接 XA 接口，Seata 数据源代理统一处理了这些底层细节。
2.3 XA 和 AT 的根本差异
我一度以为 Seata 的 XA 模式和 AT 模式只是实现方式不同，深入对比后才意识到它们在架构思路上有本质区别。
AT 模式是“业务 SQL 直接提交，用 undo log 反向补偿”。第一阶段直接执行业务 SQL，并生成对应的 undo log，然后提交本地事务。如果全局事务需要回滚，就根据 undo log 反向执行补偿 SQL。这种模式对业务代码侵入很小，但没有锁定数据库资源，提交后其他事务可能读到中间数据，因此它本身不保证强隔离。
XA 模式是“分支事务由数据库原生事务管理，提交前锁定资源”。第一阶段执行 SQL 后，数据库层面就把相关记录锁住了，XA 连接进入待提交状态。全局事务提交前，其他事务对这些记录的更新会被阻塞。这种模式的隔离性更好，数据也是强一致的，代价是并发能力会下降，锁持有时间长，死锁概率也更高。
两者选型，我的经验是：数据强一致要求严格，比如账户余额、订单状态这种不能出现任何不一致的场景，优先 XA；并发量高、允许短暂数据不一致可以用补偿方案，优先 AT；如果你不想动 SQL、不想写 undo log 相关的配置，XA 这种数据库原生能力反而更省心。
3. Seata XA 模式的架构与事务流程
3.1 整体架构角色分布
Seata XA 模式下，架构涉及三个层次。最上层是 Seata Server（TC），独立部署，管理全局事务的提交和回滚；中间层是各个微服务应用，内含 TM 和 RM；最底层是各服务的数据库，它们通过 XA 协议参与全局事务。
这里有个容易被忽略的细节：每个服务的数据源必须通过 Seata 的DataSourceProxyXA进行包装，因为 Seata 需要控制连接的实际 XA 操作。如果业务代码用了原生数据源，Seata 就无法感知到分支事务的存在，全局事务自然不生效。
3.2 全局事务开启流程
XA 模式的完整执行流程如下：
一、TM 发起@GlobalTransactional标注的全局事务，向 TC 注册全局事务，拿到全局事务 ID（XID）。
二、XID 通过微服务调用的链路传递，下游服务从 RPC 上下文里获取到 XID，加入同一个全局事务。
三、每个服务执行业务 SQL 前，RM 先从数据源代理中获取 XA 连接，并执行 XA start，标记当前连接进入 XA 分支事务。
四、业务 SQL 正常执行，在数据库层面完成数据变更，但连接处于未提交状态。
五、RM 执行 XA end，标记分支事务准备结束，然后向 TC 注册分支事务，并执行 XA prepare，数据库锁定相关资源，进入待提交状态。
六、所有分支事务都 prepare 成功后，TM 向 TC 发起全局提交，TC 通知各 RM 执行 XA commit，数据库释放锁，数据最终落库。
七、如果任一分支事务 prepare 失败或超时，TM 触发全局回滚，TC 通知各 RM 执行 XA rollback，数据库撤销改动。
3.3 会话与连接管理
XA 模式特别要注意的是连接管理。数据库的 XA 事务需要和一个物理连接绑定，在这个 XA 事务结束之前，这个连接不能被释放回连接池，更不能被其他线程复用。Seata 在数据源代理层对连接做了与业务事务同生命周期的管理，事务结束后才把连接归还连接池。
这也带来一个实际体验上的问题：当你用 Seata Server 默认的超时配置跑高并发压测时，连接池非常容易被打满。因为一个全局事务在 prepare 前的整个时间段，每个参与的 RM 都占用着一条物理连接，如果业务 SQL 执行慢或者事务范围控制不好，连接很快就会被全部占光，后续请求只能排队等待。
4. 代码实操：订单与库存场景的 Seata XA 配置
4.1 场景设定
我以最常见的订单系统作为演示：用户下单，订单服务写一条订单记录，库存服务扣减一件商品库存，如果扣库存失败，订单也不能存在。为了模拟分布式，订单服务和库存服务各连一个独立的 MySQL 数据库。
技术栈我选用 Spring Boot 2.6.13、Seata 1.5.2、MyBatis-Plus、MySQL 8.0、Nacos 2.2.1 作为注册配置中心。这套组合比较通用，实际项目里换成 Seata 1.6.x 或 2.x 也可以，配置差异不大。
4.2 部署 Seata Server
Seata Server 需要单独下载，我用的 1.5.2 版本。解压后在conf/application.yml里修改注册中心和配置中心地址，指向本机的 Nacos：
seata: registry: type: nacos nacos: application: seata-server server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP username: nacos password: nacos config: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP username: nacos password: nacos启动后确认控制台打印出Server started，并且在 Nacos 服务列表里能看到 seata-server 实例，说明服务端注册成功。这里很容易踩坑的是 group 不一致，Seata Server 默认注册到SEATA_GROUP，应用侧配置如果用了别的分组，发现服务会失败。
4.3 应用侧引入依赖与配置
两个服务的 pom.xml 里都需要引入 Seata 依赖：
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> <version>2021.1</version> </dependency>注意这个 starter 自带了一个 Seata 版本，如果想固定成 1.5.2，建议显式引入 seata-all：
<dependency> <groupId>io.seata</groupId> <artifactId>seata-all</artifactId> <version>1.5.2</version> </dependency>版本不一致会导致各种奇奇怪怪的问题，尤其要注意 Seata Server、starter、seata-all 三者尽量保持同一版本。
application.yml 里的关键配置如下：
seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP config: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP这里tx-service-group必须和 Seata Server 配置里的虚拟服务组映射关系对应上。Seata Server 的conf/application.yml里有类似这样的配置：
service: vgroup-mapping: my_test_tx_group: default意思是名为my_test_tx_group的事务分组映射到 Seata 集群的default集群。如果这个映射对不上，应用会一直提示无法获取对应集群的 TC 服务。
4.4 数据源代理配置
这是 XA 模式能否生效最关键的一步。业务代码里不能直接用原生数据源，必须包一层 Seata 的 XA 数据源代理。我按实际项目里的写法给一个参考：
@Configuration public class DataSourceConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource") public DataSource dataSource() { return new DruidDataSource(); } @Bean public DataSource dataSourceProxy(DataSource dataSource) { return new DataSourceProxyXA(dataSource); } @Bean public SqlSessionFactory sqlSessionFactory(DataSource dataSourceProxy) throws Exception { SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean(); factoryBean.setDataSource(dataSourceProxy); factoryBean.setMapperLocations( new PathMatchingResourcePatternResolver().getResources("classpath:mapper/*.xml")); return factoryBean.getObject(); } @Bean public SqlSessionTemplate sqlSessionTemplate(SqlSessionFactory sqlSessionFactory) { return new SqlSessionTemplate(sqlSessionFactory); } }上面用到了DataSourceProxyXA，这是 Seata 对 XA 数据源代理的封装类，包路径是io.seata.rm.datasource.xa.DataSourceProxyXA。只要这个 Bean 生效，Seata 就能接管连接，自动执行 XA 的 begin/prepare/commit/rollback。
之前有朋友问我能不能用DataSourceProxy（AT 模式那个类），实际是不能的。DataSourceProxy是 AT 模式的代理类，会把 SQL 解析成 undo log 的逻辑，换到 XA 模式下必须用DataSourceProxyXA，这两者不能混用。
4.5 服务间 XID 传递
订单服务调用库存服务时，需要把当前全局事务的 XID 从上游传给下游。如果你用的是 OpenFeign，Seata 的 starter 会通过请求头自动传递 XID，理论上不需要额外写拦截器。但我在实际项目中遇到过 XID 传不过去的情况，主要原因是自研 RPC 框架或者自定义的 HTTP 客户端绕过了 Seata 的过滤器，此时需要手动传递：
String xid = RootContext.getXID(); Request request = new Request.Builder() .url(url) .addHeader("TX_XID", xid) .build();接收方也要在进入业务代码前从请求头取 XID 并绑定到当前线程：
String xid = request.getHeader("TX_XID"); if (StringUtils.hasText(xid)) { RootContext.bind(xid); }用 OpenFeign 的话则不需要这么麻烦，但要注意调用链上不能有异步线程，因为 ThreadLocal 里的 XID 默认不会传到子线程，一旦你用了异步编排，XID 就断了。
4.6 核心业务代码
订单服务的下单方法上加全局事务注解：
@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private StockFeignClient stockFeignClient; @Override @GlobalTransactional(rollbackFor = Exception.class) public void createOrder(Order order) { // 本地插入订单 orderMapper.insert(order); // 远程扣减库存 StockDTO stockDTO = new StockDTO(); stockDTO.setProductId(order.getProductId()); stockDTO.setCount(order.getCount()); stockFeignClient.deductStock(stockDTO); } }库存服务端的扣减逻辑就是一个普通的本地事务方法：
@Service public class StockServiceImpl implements StockService { @Autowired private StockMapper stockMapper; @Override @Transactional(rollbackFor = Exception.class) public void deductStock(StockDTO stockDTO) { int updated = stockMapper.deduct(stockDTO.getProductId(), stockDTO.getCount()); if (updated == 0) { throw new RuntimeException("库存不足，扣减失败"); } // 故意模拟一个随机异常，验证全局回滚 if (stockDTO.getCount() > 5) { throw new RuntimeException("模拟超卖校验失败"); } } }重点理解一下：库存服务里只标了@Transactional，它负责管理本地事务，也就是 XA 分支事务的边界。Seata 全局事务的边界由发起方的@GlobalTransactional决定。两者配合，才能形成完整的分支-全局事务模型。
4.7 验证全局回滚是否生效
我把测试步骤整理成一个可复现的清单：
一、先正常下单，count 为 1，观察订单表和库存表，都成功写入和扣减，说明两条链路正常。
二、再下一单，count 设为 10，触发库存服务的“模拟超卖校验失败”异常，观察结果：订单表没有新增记录，库存也没有扣减，说明全局回滚生效。
三、在库存服务里人为制造一个超时，比如Thread.sleep(8000)，观察 Seata Server 控制台，会出现分支事务超时告警，随后事务被标记为 rollback。
实测下来，第二步能直观验证 XA 模式的两阶段提交效力：订单服务的事务也已经 prepare 成功了，但库存服务的分支失败后，TC 通知所有分支做 rollback，已经 prepare 的本地事务同样被撤销。这让我第一次意识到，XA 的强一致性确实是“参与即锁定”，不是事后补偿。
5. XA 模式实战中的常见问题与排查技巧
5.1 连接池被打满导致服务无响应
XA 模式里连接池耗尽是我遇到最多的问题，尤其是压测的时候。原因是事务内部用到的数据库连接都会在分支 prepare 之前一直占着，如果服务把@GlobalTransactional加在了一个包含大量耗时操作的方法上，比如循环调用 RPC、批量处理，事务持续时间就会被拉长，连接释放缓慢。
排查时先看连接池监控，Druid 可以开启 StatFilter 查看 activeCount，如果 active 连接长期居高不下，大概率就是全局事务内的连接没有及时释放。解决办法有几个方向：
- 缩小
@GlobalTransactional的范围，只把真正需要强一致的操作包进去，耗时操作放在事务外。 - 调大连接池的 maximumPoolSize，但要结合实际数据库最大连接数。
- 调低全局事务超时时间，让超时事务尽快回滚释放连接。
需要提醒的是，在事务里做远程 RPC 调用本身就比较危险，尤其 XA 模式下锁是真实存在的，并发一上来很容易造成死锁或者连接池耗尽。能避免就尽量避免。
5.2 事务超时时间怎么设置
Seata 1.5.x 的每分支事务默认超时时间是 60 秒，也就是说一个分支从启动到 prepare 完成不能超过 60 秒。这个参数在 Seata Server 的配置里可以修改。如果你是本地引入的配置，可以覆盖：
seata: rm: branch-rollback-retry-timeout: 30000 global-lock-retry-count: 10自定义全局事务超时可以在@GlobalTransactional里直接指定：
@GlobalTransactional(timeoutMills = 10000) public void createOrder(Order order) { // ... }这里的超时是全局事务从开启到提交的总时长上限。我之前用默认值跑过一次慢 SQL 压测，结果发现大量的全局回滚，就是因为一批分支事务执行超过了 60 秒，触发超时回滚。建议根据实际 SQL 耗时和网络开销把 timeoutMills 给到合理范围，不要一味调大，因为共享的是全局协调窗口，越长意味着锁等待越久。
5.3 MySQL 版本和驱动兼容性问题
XA 模式对数据库版本有硬性门槛。MySQL 5.7 能支持 XA，但分支事务的 crash recovery 能力比较弱，极端情况下可能出现 prepare 成功但 commit 阶段断开导致的悬空事务。MySQL 8.0.16 以上的 XA 支持才相对完善，我实际项目里也基本只用 8.0。
驱动方面，mysql-connector-java 5.1.x 和 8.0.x 的 XA 行为有差异。8.0 默认走com.mysql.cj.jdbc.Driver，一些老项目还在用com.mysql.jdbc.Driver，会导致数据源代理在初始化时识别不了 XA 支持。建议统一使用 8.0.x 驱动，并确保连接 URL 里没有禁用 XA 的相关参数。
5.4 分支事务已在数据库执行但全局回滚未生效
遇到这种情况，优先检查三处：
一是确认服务的接触点是否都走的是 Seata 数据源代理。可以启动日志里搜DataSourceProxyXA相关的初始化信息，如果没搜到，就说明数据源配置没生效。
二是确认tx-service-group的映射一致。Seata Server 的 vgroup-mapping 和应用里的tx-service-group不匹配，就无法找到正确的 TC，全局事务状态也就协调不起来。
三是确认分支事务有没有注册成功。在 Seata Server 的日志里搜分支注册相关的记录，或者打开 console 界面看全局事务状态。如果只有全局事务记录，没有分支记录，基本可以断定 RM 没参与，问题大概率出在数据源代理或 XID 传递上。
5.5 与缓存、MQ、本地消息表的配合
XA 模式只保证数据库资源之间的强一致，但你的业务不可能只依赖数据库。如果下单成功之后发送一条 MQ 消息，消息的发送和数据库提交之间是没有互动的，XA 管不到 MQ。我在实际项目里采用的方案是：数据库事务内写本地消息表，事务提交成功后，通过一个定时的消息分发组件把消息发到 MQ，发送成功后更新消息状态。这样一个全局事务里的数据库操作保持强一致，而消息投递通过最终一致来兜底，整体设计会可靠很多。
6. 面试与架构评审中的 XA 模式关键点
6.1 Seata XA 面试题常见问法
面试里分布式事务几乎是必考专题。关于 Seata XA，常见的问题有这么几类：
第一类：Seata 有哪些事务模式，XA 和 AT 有什么区别？回答时建议先讲两种模式的两阶段提交流程差异，再对比资源锁定、隔离性、一致性、SQL 侵入性。XA 强一致、锁资源、不解析 SQL；AT 最终一致、undo log 补偿、SQL 侵入小。
第二类：为什么说 XA 模式的性能较 AT 差？回答核心是锁范围和时间。XA 在 prepare 之后到 commit 之前，数据库记录的锁一直不释放，并发量高的场景下锁冲突明显。AT 在第一阶段就提交了本地事务，锁释放时间早，并发性能更好，但代价是隔离性弱。
第三类：XA 模式有什么缺点？除了性能和锁，还要提到数据库版本依赖强，不是所有数据库都能完整支持 XA 的 crash recovery；还有连接占用时间较长，对连接池容量要求更高。
6.2 项目里什么时候该选 XA
架构评审的时候，我一般建议按这几个维度去判断该不该上 XA：
第一，一致性要求。如果业务场景不允许任何短期不一致，比如用户支付、账务流水、库存扣减强校验，优先考虑 XA。
第二，并发规模。如果核心接口 TPS 很高，XA 模式的锁竞争可能撑不住。这种情况往往需要把方案拆成 TCC 或者引入消息队列做异步补偿，而不是硬扛 XA。
第三，实施成本。XA 模式在代码层面改动不大，主要是数据源代理替换和加注解，比 TCC 要简单得多。如果你的团队没时间写一堆 confirm/cancel 逻辑，XA 几乎是性价比最高的强一致方案。
第四，数据库类型的多样性。XA 要求所有参与者都支持标准 XA 协议，如果某个子系统用了不支持 XA 的 NoSQL 数据库，强制套 XA 就不现实。
6.3 XA 模式有没有办法提升性能
理论上，XA 模式的性能瓶颈主要来自两阶段提交时的锁定等待，可以从这几个方向优化：
尽量减少参与分支的数量，非核心的数据写入可以挪到事务外异步处理，让全局事务只关注最关键的数据变更。
减少全局事务内的事务耗时，拆分大事务为小事务，避免一次调用把库存、订单、账单、发票全放在一个大事务里。
合理设置隔离级别，如果业务允许读已提交，可以降低隔离级别来减少锁冲突。
扩容数据库连接池配合短事务。XA 模式下连接利用率高，短事务能显著降低锁持有时间，连接池容量和事务耗时是强相关的。
7. 从实践角度聊聊 XA 模式的选型体会
Seata 的 XA 模式并不是什么新事物，它就是包装了数据库原生 XA 两阶段提交的中间件方案。对于一个熟悉数据库事务原理的工程师来说，理解成本很低，只要没被微服务这层壳子绕晕，XA 模式的整体逻辑其实非常直白。它把分布式事务返还给了数据库，由数据库来保证真正的一致性，这对很多对数据正确性抱有执念的开发团队来说是很稳妥的取向。
我之前带过的项目里，下单链路最开始用 AT 模式，后来发现极端支付场景下出现补偿记录和实际库存对不上的情况，排查一圈才发现是本地事务提交后、undo log 执行前，别的服务已经读取到了这条中间状态数据。换成 XA 模式后再也没有出现过这种问题。当然代价也很明显，接口 RT 变长了，连接池需求变高了，压测并发上限降了一个档次。
所以我现在的选型倾向是：核心资金、核心库存场景，可以接受稍微降低并发，换成 XA；一般业务链路、允许最终一致的场景，尽量用 AT 或者消息补偿方案；如果某个接口既要求强一致又要求超高并发，那就不能单靠一种事务模式解决，需要业务上做拆分，比如热点库存独立处理、异步对账兜底。
另外要提醒一句，XA 模式包装得再好，它终究依赖底层数据库的 XA 实现。如果你们的数据库是云厂商提供的某些特殊形态，或者使用了不支持 XA 的代理中间件，上线前一定要先做全链路验证，不要等压测出了问题再去排查底层兼容性。整体而言，Seata 的 XA 模式是分布式事务领域里最接近“真正一致性”的一种落地方式，只是使用时要求你对资源开销、连接管理、分支设计有更成熟的把握，适合把稳定性放在第一位的业务场景。
