2PC 与 3PC 协议深度解析

TL;DR（30 秒扫完）

• 2PC 角色：协调者（Coordinator）+ 参与者（Participant）
• 2PC 两阶段：Prepare（参与者写 redo log + 持锁）→ Commit（全部 OK 提交/任一 Fail 回滚）
• 2PC 核心缺陷 = 阻塞：协调者崩溃在 Prepare 后/Commit 前 → 参与者持锁状态不明 → 事务永久悬挂
• redo log 三种情况：有 COMMIT→发 Commit / 无记录→发 Rollback / 只有 PREPARE→询问参与者
• 3PC 三阶段：CanCommit → DoCommit（PreCommit）→ Commit，关键改进是 PreCommit 后参与者"已提交本地事务+超时提交"
• 3PC 仍不完美：PreCommit 前崩溃、网络分区、超时提交后协调者恢复 → 仍不一致
• 工程实践：3PC 几乎不用，被 TCC/Seata AT 等柔性事务替代

关键结论

完整讲解（费曼四步）

STEP 1 · 概念

STEP 2 · 大白话

STEP 3 · 底层

2PC 完整流程

协调者                参与者1           参与者2
  │                     │                │
  ├─ Prepare ─────────► │                │
  │                     ├─ 写 redo log ─► │
  │                     │◄─ Prepare OK ───│
  │                     │                │
  ├─ Prepare ────────────────────────────►│
  │◄─ Prepare OK ─────────────────────────│
  │
  × 协调者崩溃（阻塞点）
  │
  │  参与者 1 和 2 都持有资源锁
  │  谁也无法推进 → 事务永久阻塞
  │
  恢复后：
  ├─ 若 redo log 有 COMMIT → 发 Commit
  ├─ 若 redo log 无记录 → 发 Rollback
  ├─ 若 redo log 有 PREPARE → 询问参与者，都 OK 才 Commit

2PC 三角色与两阶段

2PC 阻塞的三种场景

场景 1：协调者崩溃在 Prepare 之后、Commit 之前（最关键）
  ├─ 参与者 1 和 2 都写完了 redo log，返回 Prepare OK
  ├─ 协调者写完日志、准备发 Commit 时崩溃
  └─ 结果：参与者持有锁，状态不明，无法推进

场景 2：网络分区
  ├─ 协调者与部分参与者网络断开
  ├─ 部分参与者收不到指令，部分能收到
  └─ 结果：分区两侧的参与者状态永远不一致

场景 3：参与者崩溃
  ├─ 参与者在 Prepare 阶段崩溃
  └─ 结果：协调者等待参与者响应，无法推进（超时后可回滚）

redo log 的三种情况（协调者恢复的关键）

2PC 与 1PC 的对比

3PC 三阶段流程

阶段 1：CanCommit（询问）
  ├─ 协调者问："你能提交吗？"
  ├─ 参与者执行事务但不提交，写 undo log，不持锁
  └─ 返回 CanCommit OK / Fail

阶段 2：DoCommit（预提交）
  ├─ 全部 OK 后协调者发 PreCommit
  ├─ 参与者提交本地事务（释放本地锁！）
  └─ 等待最终 Commit/Rollback 指令

阶段 3：Commit（提交）
  ├─ 参与者收到 Commit 或超时
  ├─ 提交最终状态
  └─ 事务结束

3PC 的核心改进

• 关键差异：PreCommit 之后参与者已提交本地事务（不是 2PC 那样"持有锁等待"）
• 超时提交机制：如果协调者在 PreCommit 之后崩溃，参与者可以超时提交（因为 PreCommit 表示协调者已决定提交）
• 效果：缓解了 2PC 的"阻塞"问题

3PC 的三个未解决问题

问题 1：协调者在 PreCommit 之前崩溃
  → 参与者只能超时回滚（同 2PC，未改进）

问题 2：网络分区
  → PreCommit 发出后网络断开
  → 部分参与者提交、部分回滚
  → 不一致（3PC 无法解决）

问题 3：参与者超时提交后协调者恢复
  → 协调者可能发 Rollback
  → 已提交的参与者无法回滚
  → 不一致

2PC vs 3PC 对比表

为什么 3PC 没有替代 2PC

• 网络分区场景下 3PC 也无法保证一致性
• 引入了更多复杂度和通信开销
• 工程上柔性事务（TCC、Seata AT）比 3PC 更实用
• 3PC 主要是学术上的改进，工程上无优势

工程恢复方案（2PC 阻塞）

工程实践的现实选择

• 强一致：2PC/XA（接受阻塞代价）或 TCC/Seata AT（非阻塞）
• 最终一致：Saga / 本地消息表 / 事务消息
• 3PC：几乎不用，学术为主

STEP 3.5 · 3PC 超时机制的核心洞察（Q10 关键纠正）

很多人误以为 3PC "只是多加一次检查"、"没有真正解决阻塞"——这是错的。3PC 的核心创新是超时机制：参与者通过"已到达哪个阶段"自主决策，避免等待协调者。

3PC 超时机制的两条决策规则

• 2PC 参与者只有一阶段（Prepare），超时后只能等待——这就是阻塞
• 3PC 参与者有两阶段（CanCommit 和 PreCommit），超时后能根据阶段自主决策

3PC 残留阻塞场景深度剖析（三个真实场景）

场景 A：网络分区下的脑裂（最严重）
  1. 协调者已发出 PreCommit
  2. 网络分区让部分参与者没收到 PreCommit
  3. 未收到 PreCommit 的参与者超时后按"只到 CanCommit"逻辑回滚
  4. 收到 PreCommit 的参与者按"到 PreCommit"逻辑提交
  5. 结果：分区两侧状态永久不一致（脑裂）

场景 B：TC 崩溃在 PreCommit 后、DoCommit 前
  1. 部分参与者收到 PreCommit 并超时提交
  2. 部分参与者因为网络抖动还没收到 PreCommit 就超时
  3. 后者的超时逻辑是"只到 CanCommit → 回滚"
  4. 结果：同一批参与者状态不一致

场景 C：TC 崩溃在 CanCommit 阶段
  1. 所有参与者只收到 CanCommit
  2. 超时后全部回滚
  3. 结果：无一致性问题，但事务全部回滚（可用性损失）

STEP 3.6 · 为什么工程不用 3PC？四层原因

STEP 3.7 · Paxos / Raft / ZAB 从 3PC 演化而来的传承

3PC (2000s 前)
  ↓ 引入"预提交建立共识基础"
Paxos (Lamport, 1998)
  ↓ 引入"多数派共识"（不需要所有参与者同意）
  ↓ 解决了 3PC 在网络分区下的脑裂问题
Raft (2014)
  ↓ 把 Paxos 工程化
  ↓ 引入"领导者选举"+"日志复制"两个明确概念
  ↓ 强一致性：只允许 Leader 接收写请求
ZAB (Zookeeper)
  ↓ 使用"PreCommit + Commit"双阶段（类似 3PC 结构）
  ↓ 加上 zxid 全局递增

• 3PC：所有参与者都必须同意（一致决策）
• Paxos：只要多数派同意即可（多数派决策）
• 少数派分区时不参与决策，避免脑裂
• 这就是 CAP 定理中 P（分区容错）的必然结果

• 注册中心/配置中心 → Zookeeper（ZAB）或 Etcd（Raft）
• 分布式锁/元数据存储 → Zookeeper 或 Etcd
• 数据库分布式事务 → Paxos / Raft（如 TiDB）
• 业务层分布式事务 → Seata AT / TCC（不用共识算法）

STEP 4 · 简化

一句话总结：2PC 阻塞的本质 = "持有锁 + 状态未知 + 无超时"；3PC 用"预提交+超时提交"缓解但不完美；工程上选 TCC/Seata AT 而不是 3PC。

常见误区

延伸追问

速查表

关联题目

• ⚠️ 《什么是分布式事务中的两阶段提交（2PC）》— 2026-09-23 Round 2 Q2, ⭐⭐⭐, 未提 redo log 和阻塞本质
• ⚠️ 《2PC 协议阻塞问题详解》— 2026-09-23 Round 2 Q8, ⭐⭐⭐, 未讲 redo log 三种情况和"不确定状态"
• ⚠️ 《详细对比 2PC 和 3PC》— 2026-09-23 Round 2 Q9, ⭐⭐⭐, 未讲 PreCommit 超时提交机制
• ⚠️ 《3PC 的核心改进点 & 为何工程实践不用》— 2026-10-10 Round 1 Q10, ⭐⭐, 核心理解反了（认为"没真正解决阻塞"）

关联知识

• 分布式事务概览与模式分类
• Seata AT 模式
• 跨境支付方案设计
• MySQL 事务核心