分布式事务与一致性：两阶段提交2PC

可视化演示

演示分布式事务中两阶段提交的协调流程，从准备阶段Vote收集、提交阶段Commit广播到最终一致，展示参与者状态与阻塞、单点等关键问题。

分布式事务背景：一桌菜为什么不能一人做

年夜饭从来不是一个人的战斗。就算家里有位厨神，十道菜、两个灶眼、一场晚会的时间，也容不得他慢悠悠一道一道来。于是分工是必然的：有人蒸鱼、有人炖肉、有人拌凉菜。可分工之后新的麻烦出现了——怎么保证所有菜能在同一时刻热腾腾地上桌？如果各做各的，你炒完了我在切，你端上桌我在等油热，整桌菜就“不一致”了。

计算机世界也一样。早年的单体应用，所有数据都放在同一个数据库里，一个事务靠数据库自带的 ACID 特性就能保证“要么全成功、要么全失败”。可当业务越做越大，订单数据、库存数据、用户数据被拆到不同的数据库甚至不同的服务中，一个操作就可能要同时修改多个库。比如用户下单，订单库要插入一条记录，库存库要扣减一个数量——如果这两件事不在同一个数据库里，普通的本地事务就无能为力了。

于是，分布式事务登上了舞台。它要解决的核心问题是：让分散在不同节点上的多项操作，表现得像在同一个数据库里执行一样。这背后绕不开 CAP 理论——在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者难以兼得，必须有所取舍。2PC 站在“强一致性”这一边，追求的是让所有节点始终保持一致。

这就好比十道菜每道有 1% 的失误率，全部顺利出锅的概率只有九成左右。靠“各凭运气”显然不行，必须请出一位总指挥来统一调度——两阶段提交由此登场。

两阶段提交原理：先备菜，再统一开火

张爷爷把年夜饭的规矩定成了铁律。第一步，所有人都把菜洗好、切好、腌好，然后向张爷爷举手喊“我准备好了”；第二步，张爷爷看到十只手全部举起，才喊“开火”，大家一起下锅翻炒。若有人喊“我还没好”，张爷爷就宣布“今天不做了”，所有人放下刀铲，各回各家。这套流程听起来朴素，却是 2PC 最核心的思想。

在 2PC 中，张爷爷就是“协调者”（Coordinator），各位厨子就是“参与者”（Participant）。整个协议分两轮。第一轮叫“准备阶段”（Voting Phase），协调者向所有参与者发送 PREPARE 请求，参与者在本地执行事务操作、写入 undo/redo 日志，但并不真正提交，然后回复 YES 或 NO。第二轮叫“提交阶段”（Commit Phase），协调者收集全部投票——如果所有人都说 YES，就广播 COMMIT，所有参与者正式提交；只要有一个说 NO，就广播 ABORT，所有参与者回滚。

这里最精妙也最反直觉的一点是：参与者在“准备阶段”虽然干活了，但没有真正落锤。就像厨子们把鱼切好、肉腌好，但还没有下锅——此刻反悔完全来得及，倒掉食材重来即可。这种“先做预备工作、不急于定局”的设计，保证了最终决策可以全局统一。

张爷爷的决策规则也是如此：十个人都说“准备好了”就开火，有一个说“没Ready”就休整重来。所有菜同时下锅、同时上桌，年夜饭的“原子性”就有了着落。

关键协议流程：记好菜谱，遇到意外不乱套

张爷爷的规矩里还藏着一个细节：他要求每位厨子一边备菜，一边在菜谱本上记下自己切了什么、腌了什么、用了哪口锅。万一有谁中途肚子疼离场（故障），其他人可以翻开他的本子，替他把半成品收好或倒掉，绝不让“做到一半的菜”留在厨房里。

这正是 2PC 里的“日志记录”。协议不是简单发两条消息了事，每一步都伴随着持久化的日志，这是系统故障后能够恢复的依据。完整的流程可以拆成四步：首先，协调者向所有参与者发送“准备提交”请求，这是投票的发起；其次，各参与者执行本地事务，若成功就写入 undo/redo 日志并回复 YES，若失败则回复 NO；再次，协调者收集全部投票，依据上一节的合取规则做出全局决定，并把决定写进自己的日志；最后，协调者向所有参与者广播 COMMIT 或 ABORT，各参与者按指令提交或回滚。

日志是整个协议的“保险丝”。参与者如果不幸在准备阶段之后宕机，重启后可以根据 undo 日志回滚未完成的事务；协调者若在发出 COMMIT 后宕机，重启后也能靠日志找到“我当初答应了谁”，把 COMMIT 消息重新发给尚未收到指令的参与者。没有日志，故障恢复就无从谈起。

就像张爷爷数举起的手——十只手全部举起才喊开火，少一只都要喊停。菜谱本保证了无论谁临时离场，这顿饭的进度都不会丢。

两阶段提交的缺陷：堵车、指挥失灵与决策混乱

这套年夜饭方案听着完美，实际操作却有几个扎心的隐患。第一个：张爷爷必须等最慢的人。有位厨子备菜要三个小时，其他九个人就只能握着菜刀干等，谁也不敢先下锅。第二个：万一张爷爷自己心梗住院了，没人喊“开火”，十个人举着手面面相觑，这顿饭就无限期搁置。第三个：家里电话线路故障，张爷爷听不清谁举了手，有人以为开火了、有人以为还要等，厨房瞬间乱作一团。

这三个隐患恰好对应 2PC 的三大著名缺陷：同步阻塞、单点故障、脑裂。

同步阻塞是最直观的痛点。在准备阶段，参与者要持有资源锁（比如数据库的行锁），一直等到协调者给出最终指令。如果某个节点特别慢或网络抖动，其他节点只能陪着“堵车”，整个系统的吞吐量被最慢的节点死死卡住。这就是木桶效应——桶能装多少水，取决于最短的那块木板。

单点故障同样致命。协调者是整个协议的决策中心，它一旦宕机，所有参与者都悬在半空。经典的 2PC 没有超时机制，参与者不能自作主张提交或回滚，只能无限等待。就算协调者在几天后重启，恢复过程也相当复杂，因为各方状态可能已经各异。

更隐蔽的是脑裂。当协调者和部分参与者之间的网络被切断，系统被分成两个“派系”，协调者无法确认另一边的状态。它可能向能联系到的参与者发送了 COMMIT，但另一边的参与者根本没收到指令，最终出现一半提交、一半回滚的灾难性不一致。

一桌年夜饭能不能准时开席，取决于最磨蹭的那位厨子；而这个体系能不能正常运转，又全押在张爷爷一个人的健康上。两处都是单点，处处都是风险。

改进方案对比：三阶段、消息队列与最终一致

为了挽救这套“总指挥”方案，各路大厨纷纷献计。有人提出把两阶段改成三阶段：在“备菜”和“开火”之间加一个“预开小火”的动作。张爷爷先宣布“我打算开火啦”，大家各自把锅热上，但先不正式下菜。这样一来，万一张爷爷突然失联，大家至少知道他已经起了意、热了锅，不至于手足无措。这就是三阶段提交（3PC）。

3PC 把原来的两轮扩展成三轮：CanCommit（询问能否提交）、PreCommit（预提交，通知做好准备）、DoCommit（正式提交）。关键改进是引入了超时机制——参与者在 PreCommit 之后若长期等不到协调者的指令，会默认执行 ABORT，而不是无限期阻塞。这个改动显著缩小了阻塞窗口，也降低了协调者单点故障的影响面。

另一派人则干脆放弃“同时出锅”的执念，提出“逐个上菜、凉了用保温罩”。这就是最终一致性方案，代表技术是本地消息表和事务消息。本地消息表把“发消息”和“业务操作”放在同一个数据库事务里，先写库、后发消息，发不出去就定时重试；事务消息则借助消息中间件（如 RocketMQ）先发送“半消息”，业务成功后确认投递，失败则回滚销毁。这些方案允许中间状态不一致，但通过重试和补偿保证所有节点最终能收敛到一致。

一顿饭想稳妥，就要多打几个电话、多确认几次，代价是大家多一点等待；想让菜凉得慢，可以用保温罩（消息队列），不必强求同秒出锅。从强一致到最终一致，本质是“对实时性的妥协”与“对可用性的追求”之间的一场长期谈判。

工程实践应用：TCC、Saga 与选型智慧

真正的大饭店办宴席，绝不只用一套方案。有的菜讲究“同时上桌”，比如脆皮烤鸭，晚一分钟皮就不脆了；有的菜则宽松得多，比如凉菜拼盘，提前备好、依次端上即可。于是大厨的工具箱里备了多种模式：TCC、Saga、消息队列，各有用武之地。

TCC 模式把一个操作拆成三个阶段：Try、Confirm、Cancel。Try 阶段像“试菜”——先尝一口看口味是否合适，同时把座位预留好（冻结资源）；口味合适就 Confirm（正式上菜），不合适就 Cancel（撤下这道菜）。它非常适合“需要预留资源”的业务，比如电商下单时先冻结库存、支付时冻结余额。TCC 的优点是灵活、不阻塞，缺点是需要业务方自己实现三个方法，改造量大。

Saga 模式则把长事务拆成一串本地事务，按顺序执行，每个步骤都配一个反向补偿操作。好比宴席上一道道上菜：先上凉菜、再上热菜、最后上甜点。如果热菜出了问题，就撤掉热菜、凉菜也一并收回（逆序补偿）。Saga 适合步骤多、周期长的业务，比如旅游预订——订机票、订酒店、订门票，任何一步失败就逐步取消前面的订单。

选型没有银弹，只有权衡。强一致要求极高、参与者少、事务短的场景，用 2PC；需要预留资源、并发不极端的场景，用 TCC；长事务、多步骤、允许中间态的场景，用 Saga；能容忍异步延迟的场景，用事务消息加本地消息表。一个成熟的系统，往往像大饭店的菜单一样，同时混用多种方案。

年夜饭也是这样：既要有统筹“同时出锅”的硬菜，也要有一道道依次上桌的凉菜。选对模式，饭局才能又稳又高效。

AI 应用场景

Python 演示

import random  class Participant:    def __init__(self, name, fail_prob=0.1):        self.name = name        self.fail_prob = fail_prob        self.prepared = False        self.committed = False     def prepare(self):        if random.random() < self.fail_prob:            return "NO"        self.prepared = True        return "YES"     def commit(self):        self.committed = True     def rollback(self):        self.prepared = False        self.committed = False  class Coordinator:    def __init__(self, participants):        self.participants = participants     def run_two_phase_commit(self):        print("=== Phase 1: Prepare ===")        votes = []        for p in self.participants:            v = p.prepare()            print(f"  -> {p.name}: {v}")            votes.append(v)         if all(v == "YES" for v in votes):            print("=== Phase 2: Commit ===")            for p in self.participants:                p.commit()                print(f"  -> {p.name}: committed")            return "COMMIT"        else:            print("=== Phase 2: Abort ===")            for p in self.participants:                p.rollback()                print(f"  -> {p.name}: rolled back")            return "ABORT"  if __name__ == "__main__":    random.seed(42)    accounts = [        Participant("账户系统A", fail_prob=0.05),        Participant("库存系统B", fail_prob=0.05),        Participant("订单系统C", fail_prob=0.05),    ]    coordinator = Coordinator(accounts)    result = coordinator.run_two_phase_commit()    print(f"\n最终结果: {result}")    for p in accounts:        print(f"  {p.name}: prepared={p.prepared}, committed={p.committed}")

1. if random.random() < self.fail_prob:用随机数模拟参与者准备阶段可能出现的故障，失败则返回 NO。
2. self.prepared = True参与者执行本地事务并进入“已准备”状态，但此时并未真正提交。
3. votes.append(v)协调者把每个参与者的投票收集到列表中，等待统一决策。
4. if all(v == "YES" for v in votes):这是提交条件的代码化表达：所有投票必须全为 YES。
5. for p in self.participants: p.commit()全票通过后，协调者广播 COMMIT，参与者逐一提交。
6. p.rollback()只要有一票反对，协调者广播 ABORT，所有参与者回滚到事务前状态。

常见误区

面试题