分布式事务方案详解与Spring Cloud集成实战指南

做后端开发久了，只要系统拆成了微服务，分布式事务这个问题就早晚会摆在面前。你在电商系统里下了一笔订单：订单服务写入一条订单记录，库存服务扣减库存，支付服务完成扣款。这三个服务通常各自独立部署、各自拥有独立的数据库。任何一个环节失败，之前写入的订单记录和扣减的库存都得撤回来。这套跨服务、跨数据库的“要么全成功、要么全失败”问题，就是典型的分布式事务场景。

这篇文章不是讲概念，而是按照实际集成的路径走一遍。先搞清楚问题本质，再把 2PC、TCC、Saga、消息事务、Seata 这些主流方案捋顺，最后落到 Spring Cloud 项目的具体配置和真实踩坑记录上。无论你现在是准备引入分布式事务，还是在评估方案阶段，这篇文章都能提供一套可以直接参考的判断依据。

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

1.1 从单体到微服务，事务边界发生了什么变化

在单体应用时代，这个场景简单得多。订单表、库存表、账户表都在同一个数据库里，一次业务操作就是在一个 Connection 上执行多条 SQL，然后统一提交或回滚。数据库的 ACID 特性替我们挡住了一切并发异常、中途断电、程序崩溃导致的数据不完整问题。@Transactional一把梭，问题不大。

拆成微服务之后，情况变了。订单服务拥有订单库，库存服务拥有库存库，支付服务拥有账户库。本地事务的边界被拆散了——订单服务只能保证自己库里的订单记录没问题，库存服务只能保证自己库里的库存扣减没问题，但是没有任何一个本地事务能把两个库的操作同时包住。

你可能会想，那我把它们放在一个方法里顺序调用不就行了？比如先插入订单，再远程调用库存服务扣减库存，最后调用支付服务扣款。代码顺序确实如此，但“顺序调用”和“整体提交”是两回事。假如订单插入成功了，库存服务调用也成功了，但支付服务超时返回异常，你以为整个方法回滚了，实际上订单和库存的写入已经提交了。为什么？因为 Spring 的@Transactional只对当前事务管理器管理的数据库连接生效，远程调用是独立的系统，根本不在同一个事务上下文里。

这就是分布式事务要解决的核心：多个服务各自持有的数据，怎么在出现失败的情况下还能保持一致。

1.2 CAP 定理和 BASE 理论为什么是绕不开的地基

讨论分布式事务之前，必须先接受一个事实：网络通信是不可靠的。CAP 定理告诉我们，在分布式系统里，一致性、可用性、分区容错性三选二，而分区容错性是必须选的，因为在分布式环境下网络分区是必然事件。剩下的就只能在一致性和可用性之间做取舍。

如果选择强一致性方案，付出的代价就是可用性下降。典型如 2PC/XA，在两阶段提交过程中，所有参与者都处于阻塞状态，只要一个参与者超时，整个事务就必须停顿等待或回滚，系统的吞吐量和可用性都会受到影响。如果选择高可用方案，那就得接受数据在一段时间内是不一致的，最终靠某种机制收敛成一致状态。这就是 BASE 理论的核心思想：基本可用、软状态、最终一致。

落到实际业务里，真正对强一致性有苛刻要求的场景很少。比如订单和库存，就算扣减后短暂地多给用户看到某个商品还有货，只要秒级或毫秒级内同步过来，对用户来说是无感知的。真正绝对不许错的，可能只是账户余额这类资金数据。这也是我后来在方案选型时最重要的判断依据：先想清楚业务允许多长时间的不一致窗口，再去选技术方案。顺序反了，就容易为了一个不需要的强一致买一个大而不当的复杂度账。

2. 分布式事务主流方案全景拆解

2.1 强一致路线：2PC / XA 的设计逻辑和局限

两阶段提交（2PC）是最经典的分布式事务方案，也是数据库 XA 规范的基础。它的流程可以拆成准备阶段（Prepare）和提交阶段（Commit）两步。

准备阶段由事务协调器向所有参与者发送准备请求，每个参与者执行本地事务的写操作，但先不提交，把结果（成功/失败）报告给协调者。如果所有参与者都回复 OK，协调者就广播提交指令，大家统一提交；任何一个人回复失败或者超时，协调者就广播回滚指令，所有参与者回滚自己的本地事务。

这套协议在逻辑上是完备的，但它存在几个硬伤：第一，资源锁定时间长。参与者从准备阶段开始就要持有数据库锁，直到协调者最终下发提交或回滚指令，这段时间内其他事务无法操作这些数据，高并发场景下吞吐量直线下降。第二，协调者本身是单点，如果协调者在准备阶段之后、提交阶段之前宕机，所有参与者都处于未知状态，只能阻塞等待。第三，数据可见性差，参与者准备阶段写入的数据对外不可见，加长了业务链路的延迟。

实际项目中，我比较少见到直接裸用 XA 的场景，因为数据库厂商对 XA 的实现差异大，网络抖动时协调者重试逻辑难写，事务链路一长就容易变成全局锁风暴。但对一些低频、数据量小、强一致要求极高的内部系统来说，XA 仍然是一种正确的选择——正确不等于高性能，选型要看场景本身。

2.2 业务侵入路线：TCC 带来高性能也带来高开发成本

TCC（Try-Confirm-Cancel）本质上是用业务逻辑代替数据库锁来实现分布式事务的协调。它的执行阶段有三个：Try 阶段做资源检查和预留，比如库存服务在 Try 阶段锁定 N 件商品、账户服务在 Try 阶段冻结 M 元资金；Confirm 阶段真正执行提交，把预留的资源正式扣减；Cancel 阶段释放预留资源，把 Try 阶段锁定的资源回滚回去。

这个方案最大的优势是不用长时间持锁，接口调用之间没有全局阻塞，性能远高于 2PC。缺点也极其明显：每个参与者都得实现三个方法，且要为每个方法配套幂等控制。还要处理两个容易出问题的边界——空回滚和悬挂。

所谓空回滚，是指 Try 阶段根本没有执行成功或者没有执行，但 Cancel 阶段却触发了。比如网络超时导致 Try 请求丢失，全局事务判定失败后直接调用 Cancel，此时预留记录不存在，Cancel 必须能安全地“空操作过去”。

所谓悬挂，是指 Cancel 先执行完了，迟到的 Try 请求才到达，资源被“悬空”预留，永远没有后续的 Confirm 或 Cancel 来释放它。解决办法通常是在事务控制表里增加状态位，一旦确认该笔分支事务已经进入二阶段，就直接丢弃一阶段的执行请求。

TCC 的高性能是有代价的。如果团队规模小、业务模型不稳，我不建议一上来就用 TCC，因为在三个服务和二阶段之间来回排查，很容易被状态不一致问题拖垮。

2.3 最终一致路线：Saga、本地消息表与事务消息

如果业务链路很长、对实时一致性要求不高，最终一致方案往往是性价比最高的选择。

Saga 的核心思路是把长事务拆成一系列有序的本地事务，每个本地事务都有对应的补偿事务。假设一个下单流程包含创建订单、扣库存、发券三个正向操作，对应的补偿操作就是取消订单、回补库存、作废券。正向执行某个步骤失败后，Saga 会把前面已经成功的步骤按逆序逐个补偿回滚。它的实现方式分编排式和协同式两种。编排式通过一个中心化控制器统一编排各个步骤；协同式则通过事件队列在各服务之间传递驱动。Saga 几乎没有资源锁，性能很好，但业务上要接受中间状态短暂不一致。

消息驱动的最终一致也很常用。其中本地消息表的思路是：在业务数据库中建一张消息表，业务操作和写入消息放在同一个本地事务里，由消息表保证业务数据和消息同时成功。后台有一个轮询任务扫描未发送的消息，把消息投递到 MQ，消费方收到消息后处理业务，并且通过业务表状态位或者事务记录表保证幂等。这套方案逻辑简单，不引入额外中间件，缺点是把 MQ 投递的可靠性和消息表的管理逻辑耦合到了业务代码里。

事务消息则更进一步，典型代表是 RocketMQ 的半消息机制。生产者先发送一条 half message 到 MQ，MQ 不会立即把它投递给消费者；发送成功后生产者在本地执行业务事务，然后根据事务结果向 MQ 提交 commit 或 rollback。如果本地事务执行成功且 commit，MQ 才把消息变为可消费状态；如果执行失败回滚，MQ 直接丢弃消息；如果 MQ 长时间没有收到提交指令，它还会反向回查生产者本地事务的状态。这套机制把“本地业务和消息的一致性”转移到中间件层面，业务侵入相对小得多。

2.4 方案对比速查：选型前先看这张表

这张表是我的经验判断，不是绝对标准。选型时重点看业务能容忍多长时间的不一致，以及团队有没有人力维护复杂的补偿逻辑。方案越复杂，出问题的面越大。

3. Seata 集成实战：从原理到 Spring Cloud 落地

3.1 为什么 Spring Cloud 项目里 Seata 是高频选择

上面那些方案很多都需要自行实现大量补偿逻辑和幂等控制。如果不打算自己造轮子，基于 Spring Cloud 生态的技术栈里，Seata 是比较常见的落地框架。它同时支持 AT、TCC、SAGA 和 XA 四种模式，和 Spring Cloud、Dubbo 等框架都有现成的集成方案，依赖引入和配置相对简单，社区活跃度高。很多开源的后端脚手架，比如若依微服务版本之类的项目，也默认集成了 Seata，遇到过太多的人只是把官方 demo 跑通了，但完全不清楚 AT 模式的工作原理。我就把 AT 模式拆开讲清楚。

3.2 AT 模式的执行流程和核心机制

AT 模式是 Seata 的特色模式，核心思想是用拦截 SQL 加生成快照的方式，实现近似于本地事务的分布式事务体验。

它三个核心角色：TC（事务协调者，独立的服务端）、TM（事务管理器，通常就是业务入口服务）、RM（资源管理器，也就是各个业务服务的数据源代理）。使用的时候，在事务发起方的方法上加一个@GlobalTransactional注解，TM 会向 TC 注册一个全局事务，拿到全局唯一的 XID。XID 会随着分布式调用链路往下传递，下游服务拿到 XID 后，在执行本地 SQL 时向 TC 注册分支事务。

关键在 RM 的数据源代理层。Seata 会通过 DataSourceProxy 包装业务数据源，拦截下每一条 SQL，在真正执行之前解析出原始数据镜像（before image），执行 SQL 之后再获取一遍最终数据镜像（after image），把这两份镜像和 SQL 信息一起写入业务库的 undo_log 表。之后才是真正提交本地事务。

全局事务提交时，RM 会把对应的 undo_log 删除，表示该分支事务的任务完成。回滚时，RM 会拿当前数据库里的数据和 undo_log 中的 after image 做一次对比校验，如果一致就说明期间没有别的脏写，用 before image 反向生成补偿 SQL，把数据恢复成执行前的状态。如果不一致，说明有脏写，会自动记录下来并人工介入处理。

这种设计的好处是业务代码几乎零侵入，不用像 TCC 那样写一堆 Try、Confirm、Cancel 方法。代价是每次 SQL 都要生成镜像，整体性能会有一定损耗，并发量特别高的场景需要注意。

3.3 标准集成步骤：依赖、配置与代码注解

以新版 Seata（1.4.x 之后）为例，集成步骤一般分为四步，这里按先后顺序说。

第一步，部署 Seata Server（TC）。因为它是一个独立服务，需要从 GitHub 下载发行包，修改 application.yml 或 registry.conf 指向注册中心和配置中心。我通常使用 Nacos 做注册配置中心，把 application.yml 里的 registry 和 config 两部分都配置成 nacos 模式。

第二步，业务服务引入 Maven 依赖。Spring Boot 2.x 和 Spring Cloud Alibaba 控台上一般这样写：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> <version>对应你使用的 Spring Cloud Alibaba 版本</version> </dependency>

第三步，配置数据源代理。所有需要参与全局事务的业务数据源，都必须被 DataSourceProxy 包装。可以自定义一个配置类：

@Configuration public class DataSourceConfig { @Bean @Primary public DataSource dataSource(DataSource druidDataSource) { return new DataSourceProxy(druidDataSource); } }

这一步很容易被忽略。如果漏掉数据源代理，Seata 拦截不到 SQL，全局事务注册了分支事务也不会生成 undo_log，回滚必然出问题。

第四步，在每个参与事务的数据库里创建 undo_log 表：

CREATE TABLE IF NOT EXISTS `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, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

然后在订单服务的创建订单方法上加全局事务注解：

@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private StockFeignClient stockFeignClient; @GlobalTransactional(rollbackFor = Exception.class) public void createOrder(OrderDTO orderDTO) { orderMapper.insert(buildOrder(orderDTO)); OrderResult result = stockFeignClient.deductStock(orderDTO.getSkuId(), orderDTO.getCount()); if (!result.isSuccess()) { throw new RuntimeException("扣减库存失败"); } } }

这段代码里，@GlobalTransactional就是 TM 注册全局事务的入口。stockFeignClient发起的远程调用的请求头里会自动带上 XID，由 Spring Cloud Alibaba 的拦截器完成，不需要手动传递。库存服务的扣减逻辑内部如果还有本地事务注解@Transactional，也会被 Seata 的分支事务拦截。整个过程对开发者的心智负担是比较小的。

3.4 事务分组与服务端部署容易踩的细节

刚接触 Seata 的人，最容易被“事务分组”这个概念绕晕。事务分组（tx-service-group）是客户端连接的逻辑分组，不是服务名。客户端配置一个如my_test_tx_group的变量，这个变量会在服务端环境变量或配置中心中映射到一个 Seata Server 集群名称。调用链路是：业务服务通过配置的分组名找到 SeaServer 集群，从而完成 XID 的绑定和分支事务的注册。

实际项目里，每个环境集群都需要独立的分组名，比如dev_tx_group、test_tx_group、prod_tx_group。不要图省事让所有环境共用同一个分组，因为环境隔离一旦做烂，测试环境的事务状态会把生产环境的全局事务状态搞混乱。

服务端如果要做高可用，一般把 TC 集群注册到 Nacos 上，多个 TC 实例共用一个配置中心的存储数据库。TC 服务实例挂掉后，Nacos 服务发现机制会剔除不可用节点，业务客户端的调用链路会自动切换到可用节点。这里需要特别注意：TC 集群的配置中心、注册中心、数据库都必须一致，否则不同的 TC 实例各自为政，全局事务记录分散存放在不同数据库，跨节点查不到，回滚逻辑就会失效。

4. 集成过程中遇到的典型坑与排查实录

4.1 全局锁导致的死锁和性能抖动

AT 模式在真正写数据之前，会尝试获取全局锁。全局锁的粒度取决于 SQL 涉及的记录，底层是插入全局锁记录。高并发场景下这个锁竞争很激烈，一个数据行被多个事务并发修改时，其他事务都要等待。

我遇到过线上一个库存扣减接口，刚引入 Seata 时接口 p99 延迟直接翻了四五倍。排查方法比较笨：把 duba（undo_log 的辅助表）和 global_lock 相关表的大事务时间打出来，观察全局锁等待时间，发现大量时间花在select for update和全局锁记录的争抢上。

缓解措施有两个。一是从业务层面减小事务锁粒度，比如拆分维度，把一张大库存表拆成多行记录，让并发请求尽量分散到不同行。二是把高频短事务的隔离级别从默认版调整。如果业务上能够接受较小的时间窗口不一致，可以把全局事务的timeout调低，让超时事务尽快回滚，减少锁持有时间。

4.2 幂等控制没做全导致消息重复消费

无论是 TCC、Saga 还是本地消息表，所有异步补偿和重试机制都能触发重复执行。最常见的问题是一个服务收到重试消息后，库存扣减执行了两次，数据变成负数。

第一道防线是数据库的唯一约束。比如扣减流水表里对(order_id, sku_id)建唯一索引，第二次插入直接走唯一冲突，业务代码捕获后直接当成成功处理。第二道防线是状态机校验。订单状态按流程只能从“待支付”流转到“已支付”，重试消息到达时如果发现当前状态已经是“已支付”，就说明已经被处理过，直接返回成功。

补偿逻辑和正向逻辑的幂等是分开的。很多人只做了正向幂等，没做补偿幂等。问题在 Cancel 场景同样会出现，Cancel 接口要允许空操作，允许重复调用，必须做到连续调用两次 Cancel 的结果和调用一次完全一致。

4.3 事务超时导致回滚失败和悬挂问题

Seata 全局事务的默认超时时间通常是 60 秒（可在配置中修改），超时后 TM 会直接发起回滚，但此时可能有一批分支事务还在执行中。如果某个分支事务还没执行完，或者已经执行完但 undo_log 还没写入，回滚指令下发时会发现找不到对应的分支记录，这部分数据就无法自动恢复。

这类问题的典型表象是：一个订单服务调用库存服务，库存服务响应很慢，超过全局事务超时阈值，TM 通知 TC 把 XID 对应的全局事务标记为回滚。此时库存服务的本地 SQL 才刚执行完，分支事务注册成功，但全局事务已处于回滚状态。数据库里出现的结果是库存已经扣了，但订单最终没有生成。

针对这个问题，比较务实的做法是：把涉及外部 RPC 调用的耗时统计算出来，合理配置全局超时时间；同时核心链路尽量在本地事务内完成，远程调用在事务入口之前或之后发起，缩短全局事务打开的窗口期。另外，数据库层面加上失败重投逻辑，定期扫描异常状态的全局事务记录，能秒级发现处理，减少对用户影响时间的蔓延。

4.4 幂等表和状态机在订单与库存场景的落地细节

以最常见的订单与库存分布式事务为例，我在项目里一般会在库存服务中做两层保障。第一层是库存扣减流水表，结构上最少要有订单号、商品 ID、扣减数量、创建时间，订单号加商品 ID 建唯一索引，天然防重复扣减。第二层是库存预占状态机。订单创建请求到达库存服务后，先把库存状态置为“锁定”，订单支付成功后再把状态改为“扣减成功”，订单取消则改为“释放锁定”。

状态机字段一定要带版本号或更新时间，使用乐观锁来更新状态位，防止并发请求在前后状态之间互相覆盖。这里有一个容易忽略的细节：状态是存储在单独的状态表里的，而不是直接改库存表的剩余数量。因为库存表的剩余数量是一个强业务指标，如果重试消息把它扣了两次，数据错误很难回查；状态表则可以通过多套快照追踪问题。

4.5 服务间的数据通信网络问题会放大分布式事务的难度

分布式事务的成败严重依赖服务间数据通信网络的稳定性。远程调用超时后，发起方并不清楚对方到底是“执行了但响应慢”，还是“根本没收到请求”。这两种情况处理方式完全相反：前者要做幂等补偿，后者要做重试。

线上常见的现象是：订单服务调用库存服务超时，订单服务做了重试，库存服务实际收到了两次请求，第一次扣减成功但响应丢失，第二次扣减就触犯了唯一索引或库存为负。这种问题的根因不在于重试逻辑，而在于没有做好接口幂等性。我的经验是：所有跨服务写操作接口的设计，都要把“调用方可能重试 N 次”作为前提。

另外，像 OpenFeign 默认的读超时时间是 1 秒，改成 3 到 5 秒更合理，否则正常业务波动就会频繁触发超时，超时一多，分布式事务中的失败可能性就直接被放大了。结合整体微服务架构图来看，从用户入口到订单服务再到库存服务再到消息队列，每一跳的通信延迟都在为分布式事务增加不确定性的概率。

5. 事务消息与异步化思路的补充玩法

前面讲的 Seata AT 模式，本质上还是把多个服务的事务关联在同一个全局事务里同步执行。有些场景其实不需要同步分布式事务，比如积分发放、优惠券发放、流水通知这类允许延迟处理的任务。把这些操作从主流程中剥离出来，改造成消息驱动，系统的吞吐量和稳定性都能上一个台阶。

事务消息的做法在 Spring Cloud 生态里并不复杂。业务服务在本地事务里更新业务数据，同时发送一条 MQ 事务消息。消息成功发送后，由消费者异步处理后续操作。这里的关键点在于“本地业务和消息的一致性”不能被拆开。如果先更新业务数据再发送消息，消息发送失败就会导致下游漏处理；如果先发送消息再更新业务数据，下游可能在本地事务还没提交的时候就消费到了旧数据。

RocketMQ 的事务消息机制刚好覆盖了这个问题。生产者发送 half message，本地事务执行成功后再 commit，MQ 才会把消息投递给消费者。如果本地事务失败，rollback 消息会被丢弃。整个过程有一个回查机制兜底，MQ 会定期检查长时间状态未决的事务，反向请求生产者确认本地事务最终状态。

事务消息引入后，订单服务和库存服务之间的直接调用就变成了解耦的异步操作。订单服务负责把订单事务完成，通过事务消息把“扣库存”事件投递给库存服务。库存服务消费后执行扣减，成功则完成流程，失败则记录重试或进入人工处理队列。这种模式的副作用是最终一致的延迟变长了一些，但换来了系统的弹性和吞吐提升。

6. 选型经验总结：分布式事务不是银弹

做分布式事务集成，最容易被带偏的思路是“先选框架再套场景”。有人听说 Seata AT 模式开发成本低，就把所有跨服务调用都套上全局事务，运维后期发现全局锁抖动、回滚不完整、分支事务堆积，追查成本极高。

在微服务拆分的语境里，分布式事务只是众多一致性手段之一。很多时候，通过合理地调整模型，可以直接消灭分布式事务的需求。比如把订单和库存这两个强绑定操作放在同一个服务内，由这个服务独占两个数据源的管理权限，跨服务流程只保留本地事务；或者把扣库存从创建订单链路中削掉，改成事后异步校验，让下单主流程只对订单数据负责，库存支付后再校验。把模型改好之后，再配一条事务消息或一个幂等接口，就足够解决问题，可能是最高的杠杆比。

如果确认用了分布式事务，我的实际体会是：优先把关键路径上的数据模型和接口边界做严格约束，把超时配置、幂等表、状态机这些保障先定为默认要求，然后才去谈引入哪一种方案。很多问题不是分布式事务框架不行，而是周边基础防护没做足。

整个微服务模块引入分布式事务之后，数据安全性和团队开发效率在一定程度上就是对矛盾。正确的方式有两种：保持对业务边界和事务边界的通透理解，在每一个环节上都留好幂等和补偿的后手；以及根据场景特征理性选择方案，避免为了强一致而放弃系统的高可用和响应速度。

架构不是一次定型的，分布式事务也不是六边形战士。把每个操作的失败分支想清楚，把每个接口的重复调用写稳妥，把每个异常的超时时间配刁钻，这些东西串起来，才是分布式事务落地的底气。