Basic Paxos的活锁问题及为何不直接用于工业实践

[[Paxos最终值取决于Promise应答是否已包含批准值而非谁先获批]]描述的是 正常情况，但如果两个提案节点持续互相用更大的提案ID抢占对方——A的提案ID 刚让准备阶段成功，B又用更大ID发起Prepare并成功抢占，导致A的批准阶段 失败；A再用更大ID重新准备……如此循环，理论上可以无限持续下去，形成 “活锁”（Live Lock，节点都在正常工作、却始终无法达成决议）。这与死锁不同 ——死锁是没人能继续动，活锁是大家都在动却谁也到不了终点。工程实现中 通常靠引入随机超时时间来打破这种对称竞争，避免两个节点总是精确地互相 抢占。除了活锁风险，Basic Paxos还有两个限制其工业化应用的缺陷：一次 只能对单个值形成决议，且决议至少需要准备、批准两轮网络往返，高并发场景 下网络开销较大。这些缺陷共同决定了Basic Paxos更多停留在理论研究价值上， 真正的工业实践普遍转向了[[Multi Paxos靠选主把并发提案竞争简化为主节点 单向复制]]描述的Multi Paxos及其等价的派生算法（Raft、ZAB）。