企业官网建设流程全解析

做微服务的同学，大概率都遇到过同一个痛点：单体应用里一个@Transactional就能把多张表锁在同一事务里，拆成服务之后，订单要落库、库存要扣减、账户要记账，三个服务三套数据源，任何一步失败，数据就花了。这时候就必须引入分布式事务方案，而 Seata 是目前国内最主流的中间件之一。今天聊的这颗“、SEATA分布式事务——XA模式分”正是 Seata 提供的四种事务模式中，最贴近数据库原生规范、一致性最强的那个——XA 模式。本文我会从 XA 的底层设计出发，结合一个订单-库存-账户的实战案例，把 Seata XA 模式的原理、落地步骤、参数选型和调试经验一次讲透。无论你是在做技术选型，还是已经被分布式事务问题折磨过几天，这篇文章都能给你直接能用的参考答案。

1. 分布式事务问题域与 Seata 的整体设计

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

先回到最基础的场景。在单体应用里，事务的 ACID 特性由数据库自己保证：你执行一条 update，数据库写 undo log、redo log，提交时要么全部生效要么全部回滚，这种“本地事务”由单库单机完成，逻辑非常清晰。

微服务化之后，每个服务都有自己的库。下单这个动作，涉及订单服务的订单表、库存服务的库存表、账户服务的账户表，它们分布在三个独立数据库中，没有任何一个数据库能同时管理这三个数据源的提交和回滚。这个时候你调用库存服务扣减成功了，但账户服务因为网络超时失败了，订单数据已经写入，账上钱没扣成，高峰期这种问题最容易出现。

分布式事务要解决的，就是跨服务、跨数据源场景下多个资源操作的原子性。注意这里的关键不只是 ACID 里的原子性，还有一致性、隔离性和持久性：多个参与者要么全部成功，要么全部失败，并且过程中不能被其他请求读到中间态脏数据。这就是为什么分布式事务比普通接口调用的“失败重试+人工对账”麻烦得多，因为分布式事务介入的层面不是业务方法，而是资源管理器层面，也就是数据库事务层面。

1.2 Seata 的三个核心角色与事务模型

Seata 把分布式事务抽象成三个角色，理解这三个角色，后面看任何模式都会清晰很多：

• TC（Transaction Coordinator）事务协调者：独立部署的 Seata Server，负责维护全局事务状态、驱动分支事务的提交或回滚。它相当于舞台上的总指挥。
• TM（Transaction Manager）事务管理器：业务代码里加@GlobalTransactional注解的那个服务，就是事务发起方。TM 负责向 TC 申请开启一个全局事务，并决定最终提交还是回滚。
• RM（Resource Manager）资源管理器：关系型数据库连接、或者消息队列等资源，由 Seata 客户端代理接入，负责把本地事务注册为例行分支事务，向 TC 上报状态，并执行 TC 下发的提交或回滚指令。

这三者之间的配合逻辑，我用一个比较生活化的例子来解释：TM 是公司的项目经理，TC 是监理方，RM 是各个外包团队的负责人。项目经理发起一个项目（全局事务），通知监理（TC）登记；各团队负责人（RM）接手自己那部分活（分支事务），完成后上报监理；最后项目经理拍板交付，监理根据各个团队的完成情况，统一通知大家交付或者全部返工。

全局事务会生成一个全局唯一的事务编号 XID，从 TM 发起之后，这条 XID 会通过 Seata 的拦截器自动传递到下游服务的调用链中。下游服务收到带 XID 的请求，就会把本地事务注册到同一个全局事务下面，这就保证了业务上的一整条链路能纳入同一个分布式事务边界里管控。

1.3 XA 模式在 Seata 四种模式中的定位

Seata 提供了 AT、XA、TCC、SAGA 四种模式，各模式的取舍方向完全不同：

• AT 模式：Seata 的“招牌模式”，用一张 undo_log 表记录数据变更前镜像，一阶段直接本地提交，二阶段通过反向 SQL 补偿。特点是侵入小、性能好，但隔离级别较弱。
• XA 模式：基于数据库原生 XA 规范，两阶段提交，物理层面的强一致，适合对数据一致性要求极高、并发量可以接受一定损耗的场景。
• TCC 模式：业务层面的三阶段 Try-Confirm-Cancel，需要手写三段代码，性能最好但开发量最大。
• SAGA 模式：长事务场景的最终一致性协调方案，适用于业务流程长、中间允许补偿的业务。

如果把这四种模式排个“从强一致到最终一致、从易用到难用”的序列，XA 和 AT 在最两侧：XA 靠数据库锁强保证一致性，AT 靠补偿机制换取性能。很多新同学一上来就陷入“选哪种模式”的纠结，我的建议是：如果你追求的是严格的读已提交级别以上的隔离效果，且数据库支持 XA，那 XA 是逻辑最简单、最不容易出幺蛾子的选择。

2. XA 模式原理深度拆解

2.1 X/Open DTP 模型与 XA 规范的由来

XA 是 X/Open 组织发布的分布式事务处理（DTP）标准的一部分，这个标准定义了分布式事务环境下，应用（AP）、事务管理器（TM）、资源管理器（RM）三者之间的交互规范。XA 这个名称其实就是“eXtendedArchitecture”的缩写，它在 1991 年推出，迄今为止几乎所有主流关系型数据库（MySQL、Oracle、PostgreSQL、SQL Server）都原生支持。

XA 规范最核心的价值，是定义了一套用数据库自身能力实现跨库事务的协议，而不需要对业务代码做锁、补偿之类的设计。开发的角度上，它把“跨库一致性”的复杂度收拢到了数据库层面。

XA 事务的执行过程涉及三个角色：全局事务管理器负责协调整体，资源管理器负责单个数据库节点的事务执行，应用负责启动和结束全局事务。MySQL 的 InnoDB 存储引擎从很早的版本就支持 XA 语法，你完全可以在命令行手动执行XA START 'xid'、XA END 'xid'、XA PREPARE 'xid'、XA COMMIT 'xid'、XA ROLLBACK 'xid'这一组命令，来完成单机上的两阶段提交实验。

2.2 一阶段 Prepare，二阶段 Commit or Rollback

Seata 的 XA 模式，本质上是把标准 XA 流程嵌入到微服务调用链里。全局事务开启后，每个分支事务的执行流程如下：

第一阶段的 Prepare（预提交）

分支事务的本地 SQL 正常执行，但执行的连接不是普通的 JDBC 连接，而是被包装成 XA 连接的连接。在 SQL 执行完成后，数据并不会真正提交，而是执行一次XA PREPARE，把事务分支的执行结果固化到数据库的事务日志中。此时该分支相关的行记录都会加上事务锁，其他事务修改同一行数据会被阻塞。Prepare 操作执行成功，资源管理器 RM 就向 TC 上报“分支事务已准备完成，可以提交”。

第二阶段的 Commit / Rollback（全局提交或回滚）

TC 收集到所有分支事务的 Prepare 结果之后，如果全部成功，就向所有 RM 下发 Commit 指令，各个数据库执行XA COMMIT，一次性释放锁并对外可见；如果任何一个分支 Prepare 失败，或者 TC 的全局事务超时，就会下发 Rollback 指令，所有数据库执行XA ROLLBACK，锁立刻释放。因为 Prepare 阶段已经把数据变更固化在数据库内部事务日志中，所以二阶段的 commit/rollback 在数据库层面一定会成功，不太会出现干到一半丢失状态的情况。

这里有一个非常关键的细节：XA 模式下，数据库的锁是从 Prepare 开始持有，一直到全局事务完成才释放。这一点与 AT 模式完全不同，AT 的一阶段提交后锁就释放了，靠的是全局锁和补偿来兜底；XA 则用“锁得久”换“不会错”。这也是 XA 模式在高并发、长事务场景下容易成为瓶颈的根源。

2.3 Seata XA 与 AT 模式的核心差异

我整理了一张对比表，把 Seata 的 AT 和 XA 放在一起看：

AT 模式的核心功臣是 undo_log 表。它在本地事务提交前，把数据修改前后的镜像记录下来，二阶段需要回滚时，用镜像反向执行一次 SQL。这样数据库锁的持有时间被压到了本地事务范围内，性能自然好。但代价是，在另一个事务并发访问被 AT 事务处理过的数据时，如果不加全局锁，可能读到还没补偿完成的中间数据，所以 Seata 为这个场景设计了全局锁机制。XA 则完全没有这个问题，因为在 XA 分支事务 Prepare 之后，锁就在数据库层面稳稳卡住了，其他事务连读都会受到一致性约束，这种强一致是物理级别的，不是业务代码层面玩出来的花活。

3. Seata XA 模式落地实操

3.1 环境准备：Seata Server、依赖和数据库

动手之前，先把环境搭建好。我用的是 Seata 1.6.1 配合 MySQL 8.0，这是一个经过大范围生产验证的稳定组合。

第一步是启动 Seata Server。从 Seata 官方 GitHub 的 release 页面下载 server 安装包，解压后可以看到bin、conf目录。1.6.1 版本推荐使用 Nacos 作为配置中心和注册中心，你也可以用 file 模式减少依赖。我为了演示简单，用的是 file 模式，主要改conf/registry.conf：

registry { type = "file" loadBalance = "RandomLoadBalance" loadBalanceVirtualNodes = 10 } config { type = "file" }

修改好后，在bin目录执行启动脚本：

# Linux/macOS sh seata-server.sh -p 8091 -m file # Windows seata-server.bat -p 8091 -m file

Seata Server 默认监听 8091 端口，正常启动后，日志里出现Server started，说明协调者已经就绪。

第二步是确认数据库版本。XA 模式要求数据库原生的 InnoDB 引擎支持 XA 事务语义，MySQL 5.7 以上的 InnoDB 表都可以，MyISAM 之类非事务引擎不能参与。还需要确认 JDBC 驱动支持 XA 连接，我用的 MySQL Connector/J 8.0.x 没有问题。

第三步是在业务服务中引入依赖。如果你是 Spring Boot 项目，直接在pom.xml中加入：

<dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>1.6.1</version> </dependency>

然后在application.yml里做基础配置：

seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group registry: type: file config: type: file

注意tx-service-group对应的事务分组，多服务之间必须保持一致，这是 TM 和 RM 加入同一个全局事务的必要条件。

3.2 数据源改造：XAConnection 是核心

有个新手特别容易踩的坑，就是以为加了@GlobalTransactional就能用上 XA 模式，结果数据源还是普通DataSource。实际上 Seata 的 XA 模式要求对数据源做一次代理包装，用 Seata 提供的DataSourceProxyXA把原来的物理数据源包一层。

以 Spring Boot + Druid 为例，配置一个代理数据源的@Bean：

@Configuration public class DataSourceConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource.druid") public DataSource dataSource() { return new DruidDataSource(); } @Bean public DataSourceProxyXA dataSourceProxy(DataSource dataSource) { return new DataSourceProxyXA(dataSource); } }

DataSourceProxyXA内部做了什么？它会在获取数据库连接时，把普通连接包装成XAConnection，后续每次 SQL 都会自动触发 XA 事务流程：连接获取时绑定当前全局事务的 XID，事务执行结束后自动执行XA PREPARE。这个包装过程对业务代码完全透明，你该写 JPA、MyBatis 照常写。

这里有一个特别重要的细节：全局事务里每个分支服务的数据源，都要用DataSourceProxyXA代理。如果订单服务代理了、库存服务忘了代理，那库存服务的本地事务注册不进全局事务，一旦订单回滚了，库存已经扣掉，数据照样不一致。

3.3 全局事务注解与分支事务的编写方式

数据源代理到位后，业务代码的改动量其实很小。事务发起方在入口方法上加@GlobalTransactional：

@Service public class OrderService { @Resource private StorageClient storageClient; @Resource private AccountClient accountClient; @Resource private OrderDao orderDao; @GlobalTransactional(rollbackFor = Exception.class, timeoutMills = 300000) public void createOrder(OrderDTO orderDTO) { // 1. 本地订单库插入订单记录 orderDao.create(orderDTO); // 2. 调用库存服务扣减库存（RM 参与全局事务） storageClient.deduct(orderDTO.getProductId(), orderDTO.getCount()); // 3. 调用账户服务扣减余额（RM 参与全局事务） accountClient.debit(orderDTO.getUserId(), orderDTO.getAmount()); } }

库存服务和账户服务的实现长这样：

@Service public class StorageServiceImpl implements StorageService { @Resource private StorageDao storageDao; @Transactional(rollbackFor = Exception.class) public void deduct(String productId, Integer count) { int rows = storageDao.deduct(productId, count); if (rows == 0) { throw new BusinessException("库存不足"); } } }

你可能注意到了，分支服务里没有加@GlobalTransactional，而是用的普通@Transactional。这是因为 Seata 的全局事务上下文 XID 会通过 RPC 调用链自动传递，分支服务只要检测到当前线程绑定了 XID，就会在自己的@Transactional事务执行后，自动把本地事务注册到全局事务中。这个逻辑由 Seata 客户端的拦截器在框架层面完成，业务代码不需要关心。

我建议在服务间调用时，尽量使用 OpenFeign、Dubbo 这类 Seata 已经做了内置拦截器的框架，它能自动传递 XID。如果是自己封装的 HTTP 客户端，就得手动把 XID 塞到请求头里，否则下游服务感知不到全局事务，这是排障时最容易忽略的盲区。

3.4 关键配置参数解析

Seata XA 模式的相关配置项比较多，这里挑几个直接影响事务行为的重点说明：

timeoutMills（全局事务超时时间）

@GlobalTransactional注解里的timeoutMills是全局事务的最长执行时间，默认一般是 60 秒。如果全局事务运行时间超过这个值，TC 会直接判定超时并触发失败回滚。这里要特别提醒：由于 XA 模式在 Prepare 之后一直持有数据库锁，超时时间如果设得太短，一个耗时长的业务链路（比如调用外部接口、排队等待）很容易被误杀；设得太长，数据库端积累的锁等待又可能导致大面积连接阻塞。我的经验是先设一个 3 到 5 分钟的上限，结合压测实际情况往下调。

客户端与服务端的通讯超时

这类参数在seata-spring-boot-starter的默认配置里都有合理默认值，一般不需要动。但如果你的业务服务调用链特别长、分支事务特别多，建议调大seata.client.rm.reportRetryCount（事务执行结果上报重试次数），避免网络抖动导致的“误判失败”。

连接池大小

XA 模式下，数据库连接从 Prepare 阶段到二阶段结束会一直被占用。这个特性意味着你的连接池大小直接决定全局事务的并发上限。假设每个全局事务有 3 个分支，每个分支在 Prepare 后会占 1 个连接，数据库连接池总共 20 个，那能同时并发执行的全局事务最多也就 6 个左右。所以如果你的业务并发量较高，需要适当调大数据库连接池大小，并关注 Seata Server 所在机器的连接数限制。

4. 实战：订单-库存-账户三服务分布式事务

4.1 业务场景与服务拆分设计

为了讲清楚 Seata XA 模式的完整落地，我用一个电商下单场景来做演示。整个业务链路涉及三个独立的微服务和三个独立数据库：

• order-service（订单服务）：负责创建订单记录，是全局事务的发起方。
• storage-service（库存服务）：负责扣减商品库存，如果库存不足，抛出业务异常。
• account-service（账户服务）：负责扣减用户账户余额，余额不足则抛出业务异常。

这三个服务各连各的库，订单库里有order_info表，库存库里有storage表，账户库里有account_info表。通过一次模拟的下单请求，我希望能达到的效果是：订单、扣库存、扣余额要么全部成功，要么全部回滚，绝不会出现“订单建了、库存扣了、余额没扣”这种脏数据。

4.2 分支服务的数据源与事务配置

三个服务的数据源配置方法完全一样，都需要用DataSourceProxyXA包装物理数据源。以账户服务为例：

@Configuration public class AccountDataSourceConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource") public DataSource accountDataSource() { return DataSourceBuilder.create().build(); } @Bean public DataSourceProxyXA accountDataSourceProxy(DataSource accountDataSource) { return new DataSourceProxyXA(accountDataSource); } }

账务服务的 Mapper 接口：

@Mapper public interface AccountDao { @Update("UPDATE account_info SET balance = balance - #{amount} WHERE id = #{userId} AND balance >= #{amount}") int debit(@Param("userId") Long userId, @Param("amount") BigDecimal amount); }

注意这里 update 语句里加上了balance >= #{amount}条件，如果余额不足，受影响行数为 0，业务层就能据此抛出异常。这种写法既完成了扣减，又借助数据库层面条件判断避免了并发超扣，是非常实用的做法。

账户服务实现类中，我保留了@Transactional注解：

@Service public class AccountServiceImpl implements AccountService { @Resource private AccountDao accountDao; @Transactional(rollbackFor = Exception.class) public void debit(Long userId, BigDecimal amount) { int rows = accountDao.debit(userId, amount); if (rows == 0) { throw new BizException("账户余额不足"); } } }

4.3 全局事务的发起与回滚验证

订单服务的createOrder是全局事务的入口，之前已经贴过代码。现在着重说说回滚验证。我启动三个服务后，做了一组手动测试。

正常路径：请求创建一个订单，下单商品的库存是 100 件，账户余额是 2000 元，订单金额是 100 元。调用接口后，依次查询三张表，订单表多了一条记录，库存表变为 99，余额变为 1900，全程没有任何报错，数据全部提交成功。

库存不足路径：把下单数量改成 1000 件（库存只有 100 件），触发库存服务里“库存不足”的业务异常。此时再去看订单表，发现订单记录并不存在，账户余额也没有发生变化，说明全局事务把所有分支全部回滚了。这个场景是最能直观感受 XA 模式价值的，订单和账户两个分支都已经执行了 Prepare，如果用的是没有强一致保证的方案，这里大概率会留下脏数据。

余额不足路径：将账户余额改为一个低于订单金额的数值，触发账户服务抛出“账户余额不足”异常。同样，订单表没有新增记录，库存表的数量也没有变化。正是因为 XA 的 Prepare 阶段把库存扣减锁在了数据库事务里，全局回滚时 Release 就是一次完整的XA ROLLBACK，不需要像 AT 模式那样去反算补偿 SQL。

4.4 性能压测与并发观察

XA 模式一致性强，代价是并发能力受限。我在这套三服务环境上做了一轮简单压测，用 50 个并发线程连续下单，对比同一套逻辑在 AT 模式和 XA 模式下的 TPS 和平均响应时间。结果 XA 模式下的 TPS 大约是 AT 模式的 55% 到 70%，平均响应时间涨了约 50%。原因很直观：XA 分支事务在 Prepare 之后，库存行、账户行上的锁要等到全局事务结束才释放，高并发竞争同一行数据时，后面的请求只能排队等待前一个全局事务提交。

这说明 XA 模式不适合“秒杀”这类对单行数据并发修改极其密集的场景。但如果你的业务是账务对账、订单创建这类对一致性要求高、并发竞争没那么极端的情况，XA 模式带来的强一致收益远大于性能损失。选型的时候，一定要先评估自己的业务锁竞争程度，再决定上不上 XA。

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

5.1 高频问题速查表

我在调 XA 模式的过程中，陆续整理了一批高频问题，这里以表格形式放出来，方便你直接对照排查：

5.2 常见问题速查表的技术细解

上面表格里的问题，有不少需要进一步展开。比如XAER_NOTA这个错误，MySQL 官方文档里对应的是“XID 未知”，出现这个错误，意味着数据库端找不到与之匹配的 XA 分支事务状态。常见触发场景是：全局事务执行时间过长，事务协调者超时把全局事务判成失败，或者数据库连接池检测到连接空闲时间过长主动断开了连接，当 TM 下发二阶段提交指令时，数据库已经不认识这个 XID 了。我建议遇到这个错误时，第一件事不是去翻代码，而是去 Seata Server 的控制台查这个全局事务的执行耗时和状态变化，同时看数据库端的SHOW ENGINE INNODB STATUS输出，确认是否存在大量鎖等待或连接被回收的迹象。

再比如连接池耗尽问题。XA 模式锁的是数据库行，但长期占用的其实是应用侧到数据库的连接。一个典型的 50 并发压测场景，如果连接池配置了maximum-pool-size=20，很可能在压测刚开始几十秒就触发 “Connection is not available, request timed out” 报警。这个问题的解法不是无脑调大连接池，而是先减少并发链路里不必要的分支事务数量。如果某个分支只是查询操作，完全不需要加入全局事务，就不应该把它设计成全局事务的参与者。

5.3 实操心得与避坑指南

接下来分享几个我在实际项目中磕出来的经验，这些细节很少写在官方文档里，但往往比框架本身更容易绊倒人。

第一，XA 模式千万不要做长事务。SQL 执行本身可能只需要几毫秒，但如果业务代码里在网络调用、消息发送、甚至Thread.sleep上花了几百毫秒，那么整个链路的数据库锁都要陪着等。有一次我们把全局事务边界从订单创建一直延伸到发货通知，结果发现库存行锁阻塞了大量前端加购请求。后来把发货通知从全局事务里踢出去，改成事务成功后通过消息队列异步触发，锁竞争瞬间就缓解了。

第二，自定义线程池时，XID 需要手动传递。Seata 的 XID 默认绑定在线程的 ThreadLocal 里。如果你在全局事务执行过程中用了ExecutorService提交异步任务，子线程拿不到父线程的 XID，也就不会参与全局事务。解决办法是在提交任务前手动绑定：

String xid = RootContext.getXID(); executor.submit(() -> { RootContext.bind(xid); try { // 子线程中的分支事务操作 } finally { RootContext.unbind(); } });

第三，分支服务不要随意使用REQUIRES_NEW传播级别。这个传播级别会挂起当前事务并开启一个独立的新事务，导致 Seata 误判，把同一个分支事务拆成两个或者干脆注册不到全局事务里。团队里一致约定，全局事务链路里的分支服务统一使用默认的REQUIRED传播级别。

第四，XA 模式的分支服务要设置合理的重试和熔断策略。一旦网络抖动导致分支事务上报失败，TC 会在二阶段下发回滚，但这时分支事务可能其实已经成功，数据库端执行 Rollback 后数据本身没有损失。可如果因为重试机制导致同一笔业务被重复处理，反而会产生脏数据。所以全局事务接口建议做好幂等设计，比如用订单号做唯一索引，避免重复请求落地。

第五，监控数据一定要有。Seata Server 自带的控制台能查看全局事务列表和分支事务状态，但生产环境最好把 Seata 的指标接入 Prometheus 或者日志采集系统。重点监控几个指标：全局事务完成数、回滚数、平均执行耗时、分支事务持有的连接数。这些指标能在事务还是“有点慢”的阶段就暴露问题，而不是等数据库连接被拖垮之后才去找原因。

最后总结一下我对 XA 模式定位的理解：它不是性能最优的分布式事务方案，但它是正确性最容易保证的方案。如果项目里数据库种类统一、都支持 XA，业务链路不长、并发竞争可控，那 Seata XA 模式的工程复杂度其实是四种种模式里最低的，因为一致性完全由数据库原生机制兜底，不像 TCC、SAGA 那样依赖业务代码写补偿逻辑。反过来，如果你已经在用 Seata 的 AT 模式，并且被时不时冒出来的“脏读”“全局锁冲突”问题困扰，那就值得认真评估一下迁移到 XA 模式的成本——改动量往往只需要换一个数据源代理类，事务注解和业务代码完全不用动。从我踩过几次坑之后的经验看，分布式事务选型的核心不是追逐“热门方案”，而是先想清楚业务到底能不能接受补偿中间态，想清楚这一点，XA 和 AT 之间的选择基本就不会犹豫了。