分布式事务与一致性：三阶段提交3PC

可视化演示

演示3PC三阶段协调流程：CanCommit询问、PreCommit预提交、DoCommit提交，通过超时机制解决2PC协调者阻塞问题。

2PC痛点

传统婚礼筹备走了两步：先打电话问所有人“能不能来”，全说能，就发正式请柬。问题在于，请柬发出去之后，婚礼方案是定了，可万一策划人突然失联，没人知道婚礼还办不办——宾客们既不敢走，又不能走，只能干等。这就是“两阶段提交”（2PC）的致命伤：协调者一旦故障，整个事务就卡死在原地。

2PC 是分布式事务的经典方案，分 Prepare 和 Commit 两阶段。它的问题在于提交指令的“最终拍板权”完全握在协调者手里。协调者崩溃后，参与者拿不到“提交/中止”的明确指令，只能无限期阻塞，锁住的数据库资源也无法释放。这个进不去也退不出的状态，专业上叫“不确定状态”。

阻塞来自两个层面：一是协调者单点故障，没有替代者；二是流程里根本没有超时机制。参与者一旦说了 YES，就只能死等最终指令，否则自己和别人的数据就会不一致。这就像宾客已经为婚礼腾出了整个周末，却连“是否取消”都不知道，成本已经发生，结果却悬而未决。

所以 2PC 是一套“没有 Plan B”的婚礼方案。要打破僵局，就必须给流程加两个东西：一个“预先咨询”的环节，用来尽早发现谁根本来不了；一套“迟到自主决策”的规则，让大家在联系不上策划人时也能按约定行动。这两条，正是三阶段提交（3PC）的出发点。

三阶段概览

三段式婚礼方案长这样：第一通电话先问“你那天有空吗”；有空的人进入准备阶段，订机票、买礼服；直到确认所有宾客都把准备工作做完了，最后的最后才正式开席。3PC 把 2PC 的“两通知”拉长成“三确认”，每一段都有反馈、都有退路。

3PC 的全称是 Three-Phase Commit，三个阶段的英文名分别叫 CanCommit、PreCommit、DoCommit。其中 CanCommit 是最关键的增量——它像是事务的“资格预审”，让协调者在投入任何资源之前，先摸清楚所有参与者是不是真的能配合，避免 2PC 里“宣布提交才发现有人办不到”的尴尬。

完整流程是：协调者先发 CanCommit 询问，参与者投 YES/NO；全票 YES 则进入 PreCommit，参与者预留资源、写 undo 日志（回滚用的“后悔药”）、回复 ACK；协调者收齐 ACK 后进入 DoCommit，发最终提交指令，事务才真正生效。任何一步出现 NO 或超时，就广播中止、安全回滚。

这个方案用“三确认”换来了每个阶段的可退出性：每一轮都有明确的反馈信号，失败可以尽早暴露，超时可以由参与者自行兜底。代价是多了一轮网络往返，筹备周期变长。这就好比婚礼方案从“两通知”变“三确认”，仪式感更强了，沟通成本也更高了，但干等时间大幅缩短。

CanCommit阶段

三段式婚礼的第一步，是策划人挨家挨户打“咨询电话”：问每位宾客“婚礼当天你有空吗？能协调出时间吗？”。注意，这一步只问意愿、不动资源，宾客不需要订任何东西，只需要回答“能”或“不能”。如果有人明确说“不能”，婚礼就不办了，趁早拉倒。

CanCommit 本质上是事务的“资格预审”。参与者收到询问后，会检查本地资源情况：事务需要的锁能不能抢到、数据约束有没有冲突、本地会话是否健康。任何一项不满足，就投 NO。协调者一旦收到任何 NO，立即广播中止指令，整个事务快速失败、零成本退出。

这个阶段的价值在于“把失败前置”。2PC 里，参与者直到最终 Commit 阶段才可能暴露问题，之前准备的资源全部白费；而 3PC 在 CanCommit 就把大概率注定失败的提交筛掉了。虽然多了一次网络 RTT，但后续 PreCommit 阶段的开销大幅降低，整体效率反而更优。

打咨询电话的意义，是花最小的代价识别“根本不合适的宾客”。就像办婚礼前先问清楚每个人能不能来，总比人都到齐了、场地都租好了才发现主桌宾客根本没空要强得多。CanCommit 就是这第一道、也是最便宜的过滤闸门。

PreCommit阶段

第二通电话的内容是“请开始准备”：确认能来的宾客，现在开始订机票、买礼服、订酒店。这些动作还不是出席本身，但已经投入了真金白银，处于“可取消但取消要付手续费”的状态。这对应 PreCommit 阶段：资源被预留，但尚未生效。

PreCommit 阶段，协调者向所有参与者发出“预提交”指令。参与者开始做真正的本地动作：加锁、写 undo 日志、把数据变更先落盘。注意这里的落盘只是“记账”，事务还没有对外生效——有点像行李已经打包好，但人还没上车。参与者完成后把状态标记为 Prepared，并给协调者回复 ACK。

为什么这步如此重要？因为 undo 日志让“反悔”成为可能，而 Prepared 状态给了参与者“超时后自行决策”的依据。协调者收到全部 ACK 才允许进入 DoCommit；若有 ACK 超时或失败，协调者会广播中止，所有参与者依据 undo 日志回滚，相当于宾客退掉机票、拿回部分定金。

宾客把机票都订好了，手里就有了“我已准备好出席”的凭证。就算此刻策划人失联，规则也事先约定：票已订好的人，超时后自动前往婚礼现场——因为大家都已确认过意向、投入过成本，事务大概率会成功，这时候中止反而更危险。

DoCommit阶段

最后一声号令：开席！所有宾客入场，宴席真正开始。前面所有的询问、订票、备礼服，在这一刻全部兑现。DoCommit 是 3PC 中唯一能让事务生效的阶段，之前的全部工作都只是“预备动作”。

DoCommit 阶段，协调者已经收齐了所有参与者的 ACK，此时发送“正式提交”指令。参与者收到后，把磁盘上“预演”过的变更正式生效、释放锁和资源，并返回 DONE 给协调者。协调者收齐所有 DONE 后，整个事务圆满结束，如同婚礼圆满礼成。

3PC 超时设计的精妙之处在此显现：PreCommit 之后，参与者若迟迟联系不上协调者，倾向于“提交”而不是“中止”。因为走到这一步，CanCommit 已经全票通过、PreCommit 已经全员 ACK，事务继续推进的成功率远高于回滚。此时若超时后选择中止，反而会与那些已经提交的节点分道扬镳。

宾客带着已经订好的机票来到现场，即便现场有些混乱、策划人一时联系不上，大家也按规则“先入席再说”。这就是 DoCommit 阶段超时转提交的婚宴逻辑——风险最小化的选择，往往不是往回走，而是往前推进。

网络分区问题

婚礼当天突发暴雨，通信基站故障，一部分宾客收不到任何消息，另一部分宾客收到了“照常入场”的通知。策划人站在场地中央，与一部分人彻底失联。即便三阶段的规则设计得再精巧，这一刻依然无法保证所有人做同样的事。

网络分区是分布式系统最棘手的场景：协调者和部分参与者之间无法通信。如果分区发生在 PreCommit 之后，一侧参与者超时后依据规则“自行提交”；另一侧可能连 PreCommit 都没收到，超时后判定“中止”。于是，提交和中止在同一时刻并存，全局一致性被彻底打破。

这正是 CAP 定理的残酷体现：3PC 无法同时保证强一致（Consistency）和高可用（Availability）。它的超时机制只是把 2PC 的“无限期阻塞”换成了“有限时间内的自主决策”，并没有从根本上解决“决策必须一致”这一难题——在分区面前，任何协调者模型都无能为力。

无论三阶段的提醒做得多么细致，当“一半宾客以为照常开席、另一半宾客以为取消”时，婚礼注定无法办成统一的庆典。3PC 的价值是消灭了“永久等待”,代价是接受了“极端情况下可能各走各路”的现实。

工程实践

现实中，婚礼策划人反而很少用这种“三段式确认”，他们更信任“选日子前先订备选场地”或者“请一个有威望的证婚人拍板”。3PC 也一样：理论上优雅地解决了 2PC 的阻塞，但工程界几乎不直接采用它，原因很现实——它能解决的问题有限，代价却不小。

工业界的主流方案是 Paxos 和 Raft 这类“共识协议”。它们不仅能处理节点故障，还能在协调者（领导者）挂掉后选举出新的领导者继续推进，从根上避免了“单点失联全家干等”的问题。etcd、ZooKeeper 等组件的底层都基于类似思想，而不是 3PC。

那 3PC 就毫无价值吗？不是。它贡献了“启发式决策”的思想——超时后不盲目阻塞，而是依据本地状态选择提交或中止。这个思想被大量柔性事务方案继承，比如 Saga 模式、TCC 补偿。架构师选型时应该记住：需要强一致首选 Paxos/Raft 类共识协议；允许最终一致、追求高吞吐可选 Saga 或本地消息表。

好的婚礼方案不一定是最复杂的，而是最稳的。给架构师的启示是：方案选择要在“仪式感（一致性）”与“应变力（可用性）”之间做权衡。3PC 是一颗重要的理论垫脚石，但在生产环境的决策表上，它更多是“被对比的参照物”，而非“被选中的答案”。

AI 应用场景

Python 演示

"""三阶段提交(3PC)教学模拟器: 演示正常提交与超时决策"""import time  class Message:    def __init__(self, mtype, payload=None):        self.type = mtype        self.payload = payload  class Participant:    def __init__(self, pid, vote_yes=True):        self.pid = pid        self.vote_yes = vote_yes        self.state = 'IDLE'        self.history = []     def receive(self, msg):        self.history.append(msg.type)        if msg.type == 'CAN_COMMIT':            return Message('YES' if self.vote_yes else 'NO')        if msg.type == 'PRE_COMMIT':            self.state = 'PREPARED'            return Message('ACK')        if msg.type == 'DO_COMMIT':            self.state = 'COMMIT'            return Message('DONE')        if msg.type == 'ABORT':            self.state = 'ABORT'            return Message('ACK_ABORT')        return Message('UNKNOWN')  class Coordinator:    def __init__(self, nodes):        self.nodes = nodes        self.phase = 'IDLE'     def run(self):        # 阶段一: CanCommit        self.phase = 'CAN_COMMIT'        for node in self.nodes:            reply = node.receive(Message('CAN_COMMIT'))            if reply.type != 'YES':                self._abort()                return 'ABORT'        # 阶段二: PreCommit        self.phase = 'PRE_COMMIT'        for node in self.nodes:            node.receive(Message('PRE_COMMIT'))            time.sleep(0.1)        # 阶段三: DoCommit        self.phase = 'DO_COMMIT'        for node in self.nodes:            node.receive(Message('DO_COMMIT'))        return 'COMMIT'     def _abort(self):        self.phase = 'ABORT'        for node in self.nodes:            node.receive(Message('ABORT'))  def run_demo():    # 正常流程: 三阶段全票通过    nodes = [Participant(1), Participant(2), Participant(3)]    coord = Coordinator(nodes)    result = coord.run()    print('normal flow result:', result)    print('participant states:', [n.state for n in nodes])     # 超时场景: PreCommit 后协调者失联, 参与者自行提交    nodes2 = [Participant(1), Participant(2), Participant(3)]    for n in nodes2:        n.receive(Message('CAN_COMMIT'))        n.receive(Message('PRE_COMMIT'))    for n in nodes2:        if n.state == 'PREPARED':            n.state = 'COMMIT'        print('participant', n.pid, 'timeout decision ->', n.state)  if __name__ == '__main__':    run_demo()

1. reply = node.receive(Message('CAN_COMMIT'))协调者向每个参与者发送 CanCommit 询问，并接收 YES/NO 投票。
2. if reply.type != 'YES': self._abort()只要有一个参与者投 NO，立即广播中止，事务快速失败。
3. node.receive(Message('PRE_COMMIT'))参与者收到预提交后写入 undo 日志并预留资源，状态变为 PREPARED。
4. if n.state == 'PREPARED': n.state = 'COMMIT'模拟超时场景：已经准备好的参与者超时后自行提交，不再无限等待。
5. time.sleep(0.1)模拟一次消息往返的耗时，让流程更接近真实网络环境。

常见误区

面试题