两阶段提交 | Codeboy's Blog

形式陈述

两阶段提交（2PC）让固定的一组资源管理器对同一数据库事务作出共同的提交或中止决定。第一阶段，协调者发送 prepare，参与者在本地检查并把可恢复的 yes/预提交状态写入稳定日志后投票；若所有票为 yes，协调者记录并广播 commit，否则记录并广播 abort。第二阶段参与者按决定完成并确认。日志与恢复协议保证已作出的全局决定在崩溃后不反转。这里用预写日志落实顺序：参与者的 prepared 证据先于 yes 回复稳定，协调者的 commit 决定先于广播 commit 稳定。无故障且消息最终交付时，两阶段可以完成；已 prepared 而全局决定暂不可得的参与者则可能阻塞，协议不承诺在永久隔离中非阻塞终止。

固定 $n\ge1$ 个参与者，在无故障、不重试且保留最终确认的一次完整轮次中，协调者发送 $n$ 条 prepare，收到 $n$ 个投票，再发送 $n$ 条决定并收到 $n$ 个确认，共 $4n$ 条协议消息。按标识、投票与状态各占一个存储字计，协调者的投票及确认元数据为 $O(n)$ ，在只保存协调者身份、本地投票与决定的基本恢复版本中，每个参与者对该事务的协议元数据为 $O(1)$ ；若协作终止还保存全部参与者的联系表，这部分另需 $O(n)$ 。事务内容、日志载荷及其编码位数另计。这个消息与空间计数不包含稳定日志的 I/O 成本、重试和恢复流量，也不提供阻塞等待时间的上界。

直觉

prepare 阶段不是询问“现在愿不愿意”，而是要求参与者先稳定恢复事务所需的撤销/重做信息及 prepared 记录，再发出 yes。锁并不是把一块运行时内存直接写到磁盘：采用锁式隔离时，恢复流程须从持久状态重建未决事务的锁或等效意图，并在它们重新生效后才允许冲突事务继续运行。协调者只有收齐全部 yes 才能持久化 commit 决定，否则决定 abort；第二阶段传播唯一决定。阻塞来自信息不对称：已 prepared 的参与者在看不到协调者日志时，无法区分“commit 已决定但消息未到”与“尚未决定”。

两阶段提交的正常消息时序，以及协调者崩溃后参与者停留在 PREPARED 状态的阻塞场景 — 2PC：提交与阻塞

例子与边界

若某参与者投 yes 后协调者崩溃，它不能自行判断全局是否已 commit，只能保持锁和预提交状态等待恢复或向其他节点询问，因此 2PC 是阻塞协议。网络分区中原子性仍可通过等待维持，但可用性下降。这种停顿来自全局决定信息暂时不可得，不必形成资源 wait-for graph 中的循环，不能未经模型分析就等同为经典资源死锁。2PC 协调的是 commit/abort，不能在异步崩溃模型中凭空获得非阻塞共识；3PC 也依赖更强时序假设。

参与者 $P$ 写入 PREPARED 并回复 yes 后，协调者可能写入 COMMIT 随即崩溃。 $P$ 若自行 abort，会与恢复后读到 commit 的其他参与者冲突；若自行 commit，也可能在协调者其实未收齐 yes 时错误。因此它只能查询决定或等待恢复。只靠超时选择 abort 会提高可用性却破坏原子性，除非系统使用另有证明的共识/租约机制。

推论与应用

消息传递中的崩溃使 2PC 依赖 write-ahead log、幂等消息、超时与人工或启发式恢复。它协调数据库分片、消息系统和其他跨资源事务的 commit/abort，但不提供事务隔离；MVCC决定版本可见性，快照隔离规定读视图和并发写冲突，两者都与原子提交正交。

为消除单协调者阻塞，可把决定复制到共识组，而这实际上增加了更强协议，并非只调整 2PC 的超时参数。

参考资料

Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987，Ch. 7, distributed commit protocols and recovery。
Jim Gray and Andreas Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1992，Chs. 13–15, two-phase commit and transaction recovery。

形式陈述 ​

反向链接

形式陈述