分布式事务：让多位主厨协同完成一桌年夜饭

可视化演示

展示两阶段提交(2PC)、TCC补偿事务与Saga补偿链的协调流程，交互切换查看不同事务模式的执行与回滚机制。

事务与ACID重启

年夜饭协作的第一课，是搞清楚“一桌菜”到底意味着什么。在单机数据库里，你一个人掌勺——事务（Transaction）就是一组不可拆分的工作：要么全部完成，要么全部不做。数据库用 ACID 四性来约束这个过程：原子性（Atomicity）要求所有步骤像一枚硬币，不能掰成两半；一致性（Consistency）保证操作前后数据都符合业务规则，比如转账后总金额不变；隔离性（Isolation）让并发的几个事务互不偷看对方的半成品；持久性（Durability）则承诺只要提交成功，数据就不会因断电而丢失——如同菜端上桌就不会凭空消失。

单机事务的幸运在于，所有操作都在一个数据库进程内，锁、日志、回滚段都由同一个引擎管理。这就像你一个人在自己的厨房里，灶台、食材、调料尽在掌握，任何一步炒糊了，倒掉重来就是。

可一旦进入微服务架构，情况骤变。“一桌菜”分布在三个厨房里，由三位主厨分别掌勺。你的“事务”要跨进程、跨网络、跨数据库——ACID 中原子性瞬间变得艰难：你无法让三个独立的数据库共享同一个回滚日志。这就是分布式事务诞生的根本原因：用协调协议在多个独立节点之间重建“原子性幻觉”。

从另一个角度看，这个问题也可被理解为分布式系统中的经典悖论——你无法既保证“所有节点同时看到一致状态”，又保证“系统随时可用”。分布式事务的种种方案，本质上都是在这个矛盾中选择不同的妥协点。

所以，当你读到下文的所有协议时，请始终记得：每一份“一致性”的获得，都以某种“可用性或性能”为代价。三位主厨能否高效协作，取决于你选择什么样的沟通方式。

两阶段提交2PC

两阶段提交是分布式事务最经典的起点，思路极其直白：先问一圈，再统一开火。回到年夜饭场景，你就是总厨师长（协调者），三位主厨（参与者）分别在三个厨房。你拿起电话打给每一位主厨：“给你 30 分钟，把这道菜的食材备好、锅烧热，能开始炒吗？”如果三位都回答“能”，你再次逐一打电话：“现在，全体开火！”这就是两阶段提交的两轮通信——准备阶段和提交阶段。

在第一阶段（准备阶段），协调者向所有参与者发送准备请求（prepare），参与者各自执行事务操作但不提交，而是将资源锁定并回写 undo/redo 日志，然后回复“就绪”或“失败”。这里的“锁定”就像主厨把食材切好、调料摆齐，暂停在灶台前——食材被占用了，别人不能碰。只要有任何一位主厨回复“不行”（比如发现缺料），协调者就广播“全体取消”（abort），各参与者回滚已做的操作，释放锁，就像把切好的菜收回冰箱、锅底洗干净。

在第二阶段（提交阶段），协调者收到所有参与者的“就绪”后，广播提交指令（commit）。参与者收到后正式提交事务、释放资源，并回复确认（ack）。此时才真正“开火出菜”。

两阶段提交通过引入“协调者”这一角色，用两次广播换取全局原子性。它的核心价值在于：任何一个参与者都有否决权，只要有一方表示“不能提交”，整个事务就回滚——这保证了年夜饭不会出现“鱼上了但肉没熟”的残局。

然而 2PC 的致命弱点同样明显：同步阻塞和协调者单点故障。 同步阻塞是指，准备阶段所有参与者都已锁定资源，此时它们必须阻塞等待协调者的最终指令——如果协调者永久宕机，参与者就只能一直“举着锅铲”僵在那里，资源被无限期占用。更糟的是，协调者本身是单点，它挂了，整个协议就失去指挥。这个弱点在下面的时空图中更为直观。

想象你是那位等待电话指令的主厨：菜都切好了、锅也烧热了，但总厨师长的电话一直打不通。你不能把菜下锅，也不能收摊走人——只能干等。两阶段提交的“一致性”就建立在这种“大家齐步走”的强制等待之上，它解决了一致性，却牺牲了可用性。

尽管 2PC 有诸多问题，它仍是分布式事务的基石。理解它，你才能理解 3PC 为什么多一次预检，Saga 为什么完全放弃“锁”。下一节我们看看，如何给 2PC 打上补丁。

三阶段提交3PC

三阶段提交（3PC）是对 2PC 阻塞问题的一次改造。它的思路可以理解为：在开火之前，多进行一次“预检”，并且给每个人装上“超时自动决策”的保险。回到年夜饭：总厨师长先打电话问“都能做吗？”（CanCommit），大家确认后，再问“那我倒数三个数，大家准备好！”（PreCommit），最后才说“开火！”（DoCommit）。关键变化是：如果在任何一阶段超时未收到指令，参与者不再傻等，而是按预设策略自行处理。

3PC 的三个阶段如下。阶段一 CanCommit：协调者向所有参与者发送“是否可以提交事务？”，参与者只需检查自身状态（是否资源充足、是否处于可执行状态），回复 Yes 或 No。这一阶段不锁定资源，类似问主厨“你原料够不够”——主厨只需要看一眼冰箱，不必动手。

阶段二 PreCommit：如果所有参与者都回复 Yes，协调者发送“预提交”指令。参与者收到后执行事务操作、写入日志并锁定资源，然后回复“已预提交”。注意到这里仍没有真正提交，但资源已被锁定。难点在于：协调者收到所有“已预提交”后，如果一切正常，才发送“正式提交”指令。

阶段三 DoCommit：参与者收到“正式提交”后，真正提交事务并释放资源。如果协调者在阶段三超时未收到指令，参与者不会无限等待——它会根据自己当前的状态决定：如果已经完成预提交，基于“多数派已就绪”的假设，直接提交；如果还未开始预提交，则中止事务。

3PC 比 2PC 多的核心机制就是超时与降级策略：参与者在等待超时后可以自行选择提交或中止，而不是死等协调者。这显著降低了同步阻塞时间。同时，CanCommit 阶段在事务执行前先行确认，避免了资源被无意义锁定。

但 3PC 也不是银弹。它引入了新的不一致窗口：如果一个参与者超时后选择提交，而其他参与者选择中止，系统就出现了不一致。本质原因是，分布式系统的网络分区和消息延迟是无法完全消除的——这正是著名的 FLP 不可能定理所揭示的：在异步网络中，不存在同时满足“安全性”和“活性”的确定性共识算法。3PC 只是把问题概率降低，而非根除。

你已经看到：分布式事务的每一步演进，都是在“一致性保证”与“可用性保障”之间的再平衡。3PC 用“多一次通信”换“少一些阻塞”，而接下来要讲的 Saga 则干脆换了一条完全不同的赛道——不再追求强一致，而是用“补偿”来收拾残局。

Saga补偿事务

如果说 2PC/3PC 是“齐步走”式的强一致协议，Saga 则像一份允许临时乱序、最终总能调整好的流水菜单。回到年夜饭：你不再是让三位主厨同时开火，而是设计一份菜单流程：先上冷盘，再上热菜，最后上甜汤。每一步由一位主厨单独完成，不需要锁定所有食材。但问题是：如果热菜做到一半发现鱼不新鲜，你该怎么办？Saga 的答案是：倒退回去，把已经上桌的菜撤下来——撤销已经完成的步骤，这个过程叫作“补偿”。

Saga 是一种长事务解决方案，它的核心思想是：将一个分布式大事务拆分为一系列有顺序的本地事务，每个本地事务都有对应的补偿事务。正常流程下，依次执行正向事务 T₁、T₂、T₃……；如果某步 Tₖ 失败，则逆序执行补偿事务 Cₖ₋₁、Cₖ₋₂……来撤销之前已提交的步骤。

Saga 有两种执行模式：编排（Orchestration） 与 协同（Choreography）。编排模式中，一个中心协调器（类似总厨师长）显式地指挥每个步骤：“你做冷盘、你做热菜、你做甜汤”，并跟踪当前状态，失败时主动发起补偿。协同模式中则没有中心指挥，每个服务完成自己的任务后，通过事件触发下一个服务，类似流水线上的工人听到上一环节的信号就自动开工；补偿也通过事件链逆流传播。

Saga 的补偿操作必须遵循可补偿（compensatable）原则，即每个正向操作都有对应的、可执行的逆向操作。举例：预订酒店（正向）→ 取消预订（补偿）；扣款（正向）→ 退款（补偿）。这些操作是长期的、可异步执行的，且不依赖全局锁——这正是 Saga 能应对长事务的关键。

与 2PC 相比，Saga 放弃了隔离性：中间步骤的结果对其他事务是可见的。在年夜饭的比喻中，这意味着“冷盘已经上桌，客人可以开吃，即便后面热菜失败，冷盘被撤下，客人也已经看到了冷盘”。在业务上，这通常是可以接受的——比如一个旅游预订流程，用户先订机票、再订酒店，最后支付，如果酒店预订失败，系统自动取消机票，用户中途会看到“已订机票”但最终被退订。

Saga 的价值在于：它不需要参与者长时间持有资源锁，每个子事务提交后立即释放资源，系统的并发度和可用性大幅提升。代价是引入了补偿机制的复杂度，以及中间状态对外可见带来的业务妥协。

Saga 的哲学是“接受中间状态的不完美，但保证终态正确”。如果你能接受这一点，它会是许多跨服务长流程的最佳选择。而 TCC 则是那些“必须始终保持资源可控”的场景下的另一种答案。

TCC模式精讲

TCC（Try-Confirm-Cancel）是另一种补偿型事务方案。如果说 Saga 是“流水线式地事后补救”，TCC 就像预订婚宴酒席：先付定金锁定场地（Try），确认宾客数量后补尾款（Confirm），如果婚礼取消，则退还定金、释放场地（Cancel）。每一步都围绕“资源”的预留与释放展开。

TCC 将每个分布式操作拆分为三个方法。Try：尝试执行，完成业务检查并预留资源，但不真正执行业务变更。比如下单时，Try 阶段检查库存并锁定 10 件商品，但订单状态仍为“待确认”；在转账场景中，Try 阶段冻结转出金额。Confirm：确认执行，真正执行业务变更。Try 成功后，Confirm 将“锁定”变为“扣减”——库存真正减少、转账真正完成。Cancel：取消执行，释放 Try 阶段预留的资源。如果任意一个参与者 Try 失败或 Confirm 失败，协调者调用所有已成功 Try 的参与者的 Cancel 方法，释放预留资源。

TCC 的关键优势是资源全程可控：从 Try 到 Confirm/Cancel 之间，资源始终处于被锁定状态，不会出现 Saga 中“中间状态对外可见”的问题。这在财务对账、库存扣减等场景中极其重要。

TCC 的难点在于业务侵入性强：原本只需要一个更新库存的 SQL，现在必须编写 Try、Confirm、Cancel 三个方法，且要处理大量边界情况。特别是 Confirm 和 Cancel 必须保证幂等——因为网络重试可能导致重复调用，幂等性确保重复调用与单次调用结果一致。设计上常用唯一事务 ID + 状态表来去重。

与 Saga 相比，TCC 更强一致（Try 阶段锁资源，几乎无中间状态泄露）但成本更高（三方法编码、幂等控制、补偿逻辑）。TCC 适合资源竞争激烈、需要预防并发超卖的场景，如秒杀系统、库存扣减、账户余额变更。

TCC 是“用复杂度换确定性”的典型。想要资源全程受控，就要承担三方法编写的高昂成本。接下来，我们把视野拉高，聊聊当系统规模大到一定程度时，不追求强一致、只追求“最终会一致”的另一种宇宙。

最终一致性落地

在真实的互联网场景中，高并发、高可用往往比强一致更紧迫。这时候，你需要的不是“所有人同时看到正确数据”，而是“所有人都能正常干活，数据早晚会正确”。这就是最终一致性（Eventual Consistency）。回到年夜饭比喻的变体：你不再要求所有菜同时上桌，而是约定“菜做好一道就上一道，大家最终都能吃上整桌菜”。只要上菜的流程可靠，客人最后总能吃完全部菜。

最终一致性的经典落地方式是消息队列（MQ）+ 本地消息表。以电商下单为例：订单服务创建一个订单，同时向库存服务发起扣减请求。核心技巧在于，订单服务和消息表在同一个本地数据库中：创建订单时，同时在本地消息表中插入一条“扣减库存”的消息，二者在同一个本地事务中提交，保证订单与消息要么同时成功、要么同时失败。

接着，一个异步任务扫描本地消息表，将待发送消息投递到 MQ；库存服务消费消息执行扣减；扣减成功后，库存服务回调订单服务确认；订单服务收到确认后，将消息表对应记录标记为“已处理”。如果投递失败，异步任务会重试；如果库存服务处理失败，也会发一条失败消息，订单服务据此做反向操作。

这套机制的关键在于消息的可靠投递与幂等消费。网络可能中断、消费者可能宕机，因此 MQ 通常提供“至少一次”投递保证，消费者则必须做好幂等处理——同样的扣减请求重复执行，不能造成重复扣款。实践中通过业务唯一 ID（如订单号）做去重即可。

最终一致性的工程支柱还有定时对账：即使消息机制出现bug，系统定期比对订单数据和库存数据，发现不一致后通过补偿任务修复。对账是兜底方案——可以想象成饭局结束后，总管盘点每桌的菜是否齐全，差了哪道菜再回厨房补做。

最终一致性并非不做补偿，而是把补偿异步化、事件化、自动化，用“消息链”替代“强同步协调”。它换来的，是系统的高吞吐与高可用（下单请求无需等待库存扣减同步完成），代价是短暂的数据不一致窗口（用户看到“已下单”但“库存暂未扣减”）。

最终一致性是现代互联网系统的“常态”。它不追求完美的瞬间，而追求可靠的收敛。理解了这个思想，我们就能站在务实的角度，讨论最后一个问题：面对具体业务，你到底该选哪种方案？

技术选型与权衡

当你在架构评审会上被问到“这个跨服务操作怎么保证一致性”，你要做的不是背诵方案，而是基于业务场景做权衡。这就好比总厨师长决定采用哪种协作方式，完全取决于这顿饭的性质：如果是国宴（金融转账），宁可通过阻塞等待保证分秒不差；如果是自助餐（电商订单），允许菜陆续上桌，保证客人能吃到就好。

首先明确一个核心原则：没有银弹。2PC、3PC、Saga、TCC、最终一致性——每种方案都在一致性、可用性、性能、复杂度四个维度上各有取舍。选型的起点是问自己三个问题：业务是否能容忍短暂的不一致窗口？事务的平均时长是秒级还是分钟级？系统对可用性的要求有多高？

强一致需求优先的典型场景是金融转账、账户余额变更。A 账户扣款与 B 账户入款必须在同一瞬间对外可感知一致，任何中间状态都是不可接受的。这类场景通常选择 2PC 或 TCC——2PC 简单直接，但在高并发下阻塞风险高；TCC 更灵活，能控制资源粒度，缺点是编码复杂。如果业务量不大但一致性要求极严，2PC 也足够。

高可用优先的典型场景是电商下单、订单状态流转。用户下单时系统必须快速响应，不能因为库存服务慢就阻塞下单。此时 Saga 是最优解：下单、锁库存、支付、发货各为独立本地事务，通过编排或消息链串联，失败则逆序补偿。用户可能会遇到“订单已创建但支付后库存不足，系统自动退款”的体验，但这在电商场景是可接受的。

资源竞争激烈的场景，如秒杀系统、机票预订，需要防止超卖——两个用户同时抢最后一件商品，只能有一个人成功。TCC 是最佳选择：Try 阶段锁库存，保证了“确定性”，Confirm 阶段真正扣减，Cancel 释放。相比之下，Saga 在资源预留方面较弱（因为其子事务直接提交），容易超卖。

最终一致性则适用于对实时性要求不高的场景：如积分累计、通知发送。这些场景即使延迟几秒甚至几分钟，业务上完全无感，用 MQ + 本地消息表即可。

最后，用一张直觉决策表总结（不追求完备，只求建立直觉）：

分布式事务没有“标准答案”，只有“权衡答案”。下次面对这类问题，试着先把业务需求翻译成“一致性/可用性/性能/复杂度”四个评分维度，再选择对应方案。这不仅能让你的技术判断有章法，也能让同事和面试官感受到你的架构思维。

AI 应用场景

Python 演示

import randomimport time  class Participant:    """模拟一个分布式事务参与者（数据库节点）"""     def __init__(self, name, fail_prob=0.2):        self.name = name        self.fail_prob = fail_prob        self.prepared = False        self.committed = False        self.aborted = False     def prepare(self):        """第一阶段：执行本地事务但先不提交，返回是否可提交"""        time.sleep(0.1)  # 模拟网络 RTT        if random.random() < self.fail_prob:            print(f"[{self.name}] 本地资源不足，准备失败")            return False        self.prepared = True        print(f"[{self.name}] 事务已执行，资源已锁定，返回就绪")        return True     def commit(self):        """第二阶段：正式提交本地事务"""        if not self.prepared:            raise RuntimeError(f"[{self.name}] 未准备完成，不能提交")        time.sleep(0.1)        self.committed = True        print(f"[{self.name}] 已提交，资源已释放")     def rollback(self):        """回滚本地事务并释放资源"""        self.aborted = True        self.prepared = False        print(f"[{self.name}] 已回滚，资源已释放")  class Coordinator:    """两阶段提交协调者"""     def __init__(self, participants):        self.participants = participants     def run_two_phase_commit(self):        """执行两阶段提交，返回全局事务是否成功"""        print("\n===== 第一阶段：准备阶段 =====")        votes = []        for p in self.participants:            ok = p.prepare()            votes.append(ok)        if not all(votes):            print("\n===== 有参与者准备失败，执行全局回滚 =====")            for p in self.participants:                p.rollback()            return False         print("\n===== 第二阶段：提交阶段 =====")        for p in self.participants:            p.commit()        return True  def main():    # 固定随机种子，便于观察不同场景    random.seed(3)    participants = [        Participant("订单库"),        Participant("库存库", fail_prob=0.5),        Participant("支付库"),    ]    coordinator = Coordinator(participants)    success = coordinator.run_two_phase_commit()    print(f"\n全局事务结果: {'成功' if success else '回滚'}")  if __name__ == "__main__":    main()

1. class Participant模拟分布式事务中的参与者节点，每个节点有独立的提交或回滚能力
2. def prepare(self)对应 2PC 的准备阶段：执行本地事务、锁定资源、返回“是否可提交”
3. fail_prob=0.2控制参与者准备失败的概率，用来观察“有节点失败时全局回滚”的行为
4. def run_two_phase_commit(self)协调者主流程：收集所有参与者投票，全票通过才提交
5. if not all(votes)任一节点准备失败，则对所有参与者执行 rollback，保证原子性
6. random.seed(3)固定随机种子，让你每次运行看到相同的失败/成功模式，便于教学观察

常见误区

面试题