两个库，怎么一起成功或一起失败？

你下单付了钱，页面显示成功，仓库却根本没扣库存。如果订单和库存记在不同的数据库里、各记各的，就可能出现这种「一个成了，另一个没成」的情况。这一期讲：数据分在不同的库里以后，怎么还能一起成功或一起失败——也就是分布式事务。

1. 为什么本地事务不够用了

同一个库里，一笔事务要么全部生效，要么全部撤回。可它的「提交 / 回滚」只对本库的数据有效：订单库回滚，管不到库存库。数据分到不同的库以后（分库分表的代价之一就是跨库事务变难），两个库各自提交，中间任何一步失败——库存不足、网络断、进程重启——就只剩一半生效。

Azure 架构中心的说法是：单个服务在一个数据库里能遵守 ACID，跨多个服务时就复杂得多，传统的 ACID 保证「aren’t directly applicable to multiple independently managed data stores」¹。RocketMQ 文档也用电商下单举过反例：订单执行了，消息却没发出去；超时错误又没法可靠判断要不要回滚订单²。

2. 第一种，两阶段提交（2PC / XA）：先准备、再统一生效

以 MySQL 8.4 为例，XA 事务让多个独立的事务资源参与同一个全局事务，「either all components must commit, or all components must roll back」³。

• 角色：事务管理器 TM（协调者，比喻里拿对讲机的调度员）+ 各个资源管理器 RM（每台 MySQL，比喻里听调度员指挥的驿站）。连到 MySQL 的客户端程序充当 TM³。
• 第一阶段：所有分支先 prepare，各 RM 把本分支的动作记到稳定存储里，并回报能不能提交（铅笔写好、货锁进待出库格子，再举绿牌或红牌）³。
• 第二阶段：全都能提交，TM 让所有分支提交；有一个不能，就让所有分支回滚（一起盖章 / 全部擦掉）³。

MySQL 里的语句大致是 XA START → 执行 SQL → XA END → XA PREPARE → XA COMMIT（或 XA ROLLBACK）。

代价：进入 PREPARED 状态的 XA 事务会一直保留，直到显式执行 XA COMMIT 或 XA ROLLBACK⁴，可以用 XA RECOVER 查出还悬着的事务。也就是说，投了「准备好」以后，参与者自己不能决定，只能等协调者；协调者挂了，它就悬着，相关数据一直被占着（好比「对讲机没声了，只能干等」）。RocketMQ 文档也定性地指出 XA 要锁住大量资源，并发低²。另外 MySQL 对 XA 还有复制过滤、binlog 分段写等限制，见手册⁴。

3. 第二种，TCC：先预留，再确认或取消

Seata 文档：TCC 是两阶段提交里资源管理器的一种「面向服务」的实现；Try 负责检查并预留资源，是第一阶段；Confirm 是第二阶段提交；Cancel 是第二阶段回滚，释放预留、恢复原状⁵。它不依赖底层数据库，能缩短资源锁定的时间（reduces resource lock holding time），但要业务系统自己实现 Try / Confirm / Cancel 三个动作，设计相对复杂⁵，还要处理幂等、空回滚、悬挂。

用驿站说：不让数据库一直锁着，改成业务自己贴封条——蓝站先在货上贴「已预留」封条，货还在架上但别人买不走（Try）；之后还是由调度员（协调者，Seata 文档里由 TM 分两阶段协调）喊确认或取消：订单成了就撕封条真出库（Confirm），没成就撕封条、货照常卖（Cancel）⁵。一致性怎么说：Seata 的原话是由 TM 分两阶段协调，保证所有资源的最终状态一致——要么都提交，要么都回滚（简单说：最后要么都确认，要么都取消）⁵。本文不把 TCC 称为「强一致」：Try 之后、Confirm 之前，预留是业务层的，不是数据库锁。「防着同一个指令重复送来」，就是 Seata 说的幂等问题⁵。Pat Helland 把这种做法叫 tentative operation（暂定操作）：对方先接受不确定，之后收到确认或取消⁶。

版本：Apache Seata（孵化项目）最新正式版 2.6.0（2026-01-28）；2.7.0 目前还是 RC 预发布版，不是正式版⁷。

4. 第三种，Saga：先做，失败了再补偿

Saga 把一个事务拆成一串本地事务；某一步失败，就执行一系列补偿事务，抵消前面已经做过的改动¹。组织方式有两种：编舞（choreography，各方发事件，没有中心）和编排（orchestration，有一个编排器，但它本身会成为故障点）¹。

要诚实讲清的几点¹：

• 没有内置的跨服务隔离，中间状态别人看得见；
• 已提交的改动不能真的回滚，只能用反向操作补；
• 补偿也可能失败；
• 各步骤要幂等。

用驿站说：蓝站先真把货出了库，后面红站失败，就把货「重新上架」——这是一个反向动作，不是时光倒流：已提交的改动不能回滚¹。中间那段时间别人能看见货架空了（没有隔离）；补偿本身也可能失败，要能重试且幂等¹。Azure 还指出，可重试的步骤让 saga「eventually achieve a consistent state」，即最终一致¹。Seata 2.x 也提供 Saga 模式⁷。另见 microservices.io 的总结：缺少自动回滚、缺少隔离⁸。

5. 第四种，可靠消息：先记下来，再保证送到（不自动撤回订单；永久失败要另外处理）

5.1 本地消息表（Transactional outbox，仅参考）

订单库在同一个本地事务里，同时写「订单」和「一条待发送的通知」；之后后台反复把通知投递给库存服务，直到对方确认⁹。这样就避免了「数据库改了、消息没发」的一半状态。下游要按订单号去重（幂等），因为通知可能重复送达。

5.2 RocketMQ 事务消息（半消息）

流程²：先发一条「半消息」（暂不投递）→ 生产者执行本地事务 → 提交 Commit 或 Rollback；broker 没收到结果时，会主动回查生产者这条半消息的状态。超时未决默认回滚半消息（具体时长见官方参数说明，本文不引数字）²。打个比方：条子交邮局暂存不送 = 半消息；「可以送了 / 作废」= Commit / Rollback；邮局回头问 = 回查；蓝站没处理好就再送 = 消费重试²。注意：「同一页账上同时写订单和条子」是本地消息表的做法（见 5.1，仅参考），不是 RocketMQ 事务消息；事务消息也不是「连调度员都不要」，RocketMQ 自述是「在普通消息上支持两阶段提交」。

一致性边界：它「ensures only final consistency」，也不保证下游消费结果和上游执行结果一致，下游业务必须自己保证正确处理²。版本：RocketMQ 最新 5.5.1（2026-08-20），文档按 5.x¹⁰。

6. 最终一致：Saga 和可靠消息都是

最终一致不是 Saga 或可靠消息独有的说法，这两种都是：中间会有一段时间订单和库存对不上，等补偿（Saga）或重送（可靠消息）做成了，最后再对上²¹。但不能说「最后一定对上」：Azure 明确写了补偿事务可能失败，系统会停在不一致状态，要靠监控和重试¹。

7. 方案怎么选（对照）

四格对比（一句话版）

注意区分：可靠消息本身不自动撤回订单，它保证的是通知一定送出去；临时失败靠重试，重试到上限会进死信队列，永久失败（比如库存不足）需要业务另行设计补偿或人工处理。Helland 也指出：多数分布式事务系统里，一个节点故障会让提交卡住⁶。没有哪一种「最好」，看业务能不能接受短暂对不上。