分布式事务

事务这个词在单机关系库里指 ACID：一组改动要么全成、要么全废（原子性），不会读到别人写到一半的状态（隔离性）。把它搬到分布式环境，难点不在"事务"这个概念，而在第 01 章那条主线——状态被迫跨机器存在。一旦库存表在 A 服务的库、余额表在 B 服务的库，一次业务操作就要让两个独立的存储节点对"成"或"败"达成一致。第 05 章已经证明：让多个节点对一件事达成一致需要付出代价（共识要多数派往返，或者牺牲可用性）。分布式事务就是这笔代价在"业务操作"这一层的具体账单。

本章拆四种机制，每一种都先讲它怎么提供原子性，再讲它因此付出什么、在什么条件下失效。读完应该能在一次架构评审里，对"这个跨服务操作该怎么保证正确"给出有依据的选型，而不是条件反射地说"上个分布式事务框架"。

6.1两阶段提交：原子性押在一个协调者身上

两阶段提交（two-phase commit，简称 2PC）是把单机事务的"提交"动作拆成两步，套到多个参与者身上。一个协调者（coordinator）指挥若干参与者（participant，通常是各自的数据库节点）：

• 阶段一 · prepare（准备）：协调者问每个参与者"你能提交吗"。参与者把改动写进 redo/undo 日志、锁住涉及的行，确认自己之后无论崩溃重启都能提交，然后回投 YES。投了 YES 就等于立下承诺：之后协调者一旦下令提交，该参与者必须能提交。
• 阶段二 · commit/abort（提交或中止）：只要有一个参与者投 NO，协调者广播 abort；全员 YES，协调者把"提交"这个决定先持久化，再广播 commit。参与者收到后落实改动、释放锁。

这套设计的原子性来自一个关键点：所有参与者把"自己决定提交"的权力交给了协调者。没有任何参与者能单方面决定，于是不会出现"A 提交了 B 中止了"的分叉。这也正是它致命弱点的来源。

很多人的第一反应是：那把协调者做成高可用、复制几份不就行了？这能让协调者更不容易整体消失，但救不了 in-doubt 窗口本身。问题不在协调者"会挂"，而在阶段一和阶段二之间存在一个时间窗口，参与者在这个窗口里持锁且无法自决。复制让这个窗口更难触发，却没有消除"参与者必须等一个外部决定"这个结构。2PC 是按构造（by design）阻塞的协议——这是 Gilbert-Lynch 那条铁律在事务层的回声：要强原子性，就别指望同时拿到"协调者故障时仍不阻塞"。

6.2Saga：用补偿换掉全局锁

既然跨服务持锁是 2PC 的病根，Saga 的思路就是根本不持全局锁。一个长流程被拆成一串本地事务 T₁、T₂、…、Tₙ，每一步只在自己的库里做一个普通的本地事务并立即提交。如果走到第 k 步失败了，就反向执行已完成步骤的补偿事务 Cₖ₋₁、…、C₁，把已经造成的影响一个个抵消掉。

这里的关键词是补偿（compensation），不是回滚（rollback）。回滚是数据库还没提交、直接丢弃；补偿是前一步已经真实提交、已经生效，只能再做一个语义上相反的操作去抵消它。"扣了 10 件库存"的补偿是"加回 10 件库存"；"创建了订单"的补偿是"把订单标记为已取消"。

Saga 有两种编排方式，值得在评审里分清：

• 编排式（orchestration）：一个中央 saga 编排器显式调用每一步、记录进度、决定何时补偿。逻辑集中、易追踪、易处理超时，代价是编排器成为一个需要自己保证高可用的组件。
• 协同式（choreography）：没有中央大脑，每个服务完成自己那步后发一个事件，下游服务订阅事件触发下一步。无单点、耦合低，但整条流程的状态散落在各服务里，出问题时难以看清"现在走到哪、该不该补偿"。

6.3TCC：用 pending 状态把中间值藏起来

Saga 的痛点是中间状态裸露。TCC（Try-Confirm-Cancel）针对的正是这一点——它把每个参与服务的操作拆成三个必须由业务自己实现的接口：

• Try：尝试预留资源，但不正式生效。比如扣库存的 Try 不是真扣，而是把 10 件库存从"可用"挪到"冻结（pending）"；扣余额的 Try 把金额从"可用余额"挪到"冻结金额"。
• Confirm：所有参与者 Try 都成功后，逐个 Confirm，把冻结的资源正式落实（冻结的库存真正扣减、冻结的金额真正划走）。Confirm 只操作自己 Try 阶段预留的那份，不再做业务校验。
• Cancel：任一 Try 失败，对已 Try 成功的参与者逐个 Cancel，把冻结释放回去。

关键在于：对外可见的口径里，pending 的资源既不算"还在"也不算"已用"。别的请求看到的"可用库存"已经把冻结部分排除，于是不会读到 Saga 那种"看起来还在、其实即将被扣"的中间值。隔离性因此强于 Saga——这是 TCC 相对 Saga 的核心买点：补偿（Cancel）发生在正式提交（Confirm）之前，而 Saga 的补偿发生在每步都已正式提交之后。

三者之间没有"最好"，只有"在隔离性、锁、开发成本三者间各落一个点"。2PC 用锁换隔离，Saga 用放弃隔离换不阻塞，TCC 用 pending 簿记和三倍接口换回一部分隔离。Apache Seata 这类框架把三种模式都做成可选项（它的 AT 模式本质是自动化的 2PC 变体，另有 TCC、Saga 模式），正说明业界承认没有银弹——选型取决于这一笔操作能容忍什么。

6.4双写问题与发件箱：当一边是数据库、另一边是消息队列

前三节假设各参与者都是数据库。但现实里最常见的跨系统操作是另一种形态：一次操作既要写数据库、又要发一条消息。下单成功要落订单行，同时要往消息队列发一条"订单已创建"事件，让物流、积分、推荐等下游异步消费。这两个动作落在两个完全不同的系统（数据库 + broker）上，没有一个共同的事务能把它们包住——这就是双写问题（dual-write problem）。

朴素写法是顺序执行：先写库，再发消息。两种崩法：

• 写库成功、发消息前进程崩 → 订单存在，但下游永远收不到事件，消息丢失。
• 调换顺序：先发消息、再写库失败 → 下游收到了"订单已创建"，但库里根本没有这个订单，幽灵事件。

常见的"补救"是 try/catch 加重试：发消息失败就重试几次。但这解决不了根本问题，只是把"丢事件"换成了"重复事件"——重试可能在消息其实已经发出去、只是 ack 丢了的情况下再发一次。要点：单纯的应用层重试无法让"写库"和"发消息"变成一个原子动作，因为这两个系统之间没有共享的提交协议。

发件箱（Transactional Outbox）模式

发件箱的核心洞察是：把"要发的消息"也变成一次数据库写，这样它就能和业务数据共享同一个本地事务。具体做法：

• 在业务库里加一张 outbox 表。下单时，在同一个本地事务里既插入订单行、又往 outbox 插入一条事件记录。本地事务的原子性保证：要么订单和事件都落库，要么都不落——双写被收敛成了一次单库事务。
• 另有一个 relay（投递器）进程，异步地把 outbox 表里还没发出的记录读出来、投递到 broker、然后标记为已发送。relay 有两种实现：轮询 outbox 表，或用 CDC（change data capture，变更数据捕获，如 Debezium 订阅数据库的事务日志/binlog）来感知新行。

BEGIN;
  INSERT INTO orders (id, user_id, amount, status)
  VALUES ('ord_8801', 'u_42', 199.00, 'CREATED');

  -- 同一事务里写入待发事件；原子性由本地事务保证
  INSERT INTO outbox (id, aggregate, event_type, payload, sent)
  VALUES ('evt_5512', 'order', 'OrderCreated',
          '{"orderId":"ord_8801","userId":"u_42","amount":199.00}',
          FALSE);
COMMIT;
-- relay 进程稍后轮询 / 经 CDC 读到 sent=FALSE 的行，投递后置为 TRUE

发件箱用一次本地事务换来了确定性，但它不提供 exactly-once。relay 投递成功、还没来得及把 sent 标记为 true 就崩溃，重启后会把同一条事件再投一次。因此发件箱给到 broker 的语义是 at-least-once（至少一次）——这正好呼应第 07 章的核心结论：传输层做不到恰好一次，工程上的"有效一次"等于至少一次加上消费者幂等。消费者必须基于事件里的幂等键（如 evt_5512）去重，并且把去重记录和业务副作用写进同一个事务，否则"先扣款、再写去重表"之间崩溃仍会重复扣款。