两阶段提交

prepare 阶段不是询问“现在愿不愿意”，而是要求参与者把撤销/重做信息与资源锁持久化到足以在崩溃恢复后兑现 yes。协调者只有收齐全部 yes 才能持久化 commit 决定，否则决定 abort；第二阶段传播唯一决定。阻塞来自信息不对称：已 prepared 的参与者在看不到协调者日志时，无法区分“commit 已决定但消息未到”与“尚未决定”。

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

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

消息传递公理库消息传递系统Message-passing system进程仅通过发送和接收消息交互的分布式模型。中的崩溃公理库崩溃故障Crash failure进程停止执行且此后不再采取步骤的故障。使 2PC 依赖 write-ahead log、幂等消息、超时与人工或启发式恢复。它协调数据库分片、消息系统和其他跨资源事务的 commit/abort，但不提供事务隔离公理库可串行化Serializability并发事务历史与某个串行事务次序等价的正确性条件。；MVCC公理库多版本并发控制Multiversion concurrency control · MVCC · 多版本并发控制机制通过保留多个已提交版本和显式可见性规则协调事务读写的并发控制框架。决定版本可见性，快照隔离公理库快照隔离Snapshot isolation · SI让事务读取开始时一致快照，并以先提交者获胜规则排除并发同项写入的隔离级别。规定读视图和并发写冲突，两者都与原子提交正交。

为消除单协调者阻塞，可把决定复制到共识公理库分布式共识Distributed consensus · Consensus problem多个进程在可能故障和通信延迟下对一个值达成一致的任务。组，而这实际上增加了更强协议，并非只调整 2PC 的超时参数。