Cloudflare工程师解释：为什么Raft在全球互联网上会停摆，以及QuePaxa如何用可选领导者绕过故障检测

分布式共识系统的默认选择是Raft或Paxos，它们成熟、可理解、在局域网中工作良好。但Cloudflare的Meerkat服务需要横跨大洲运行，连接链路经常表现出高且波动的延迟。三位作者João Pedro Leite、Bob Halley和James Larisch解释，正是这个环境让他们放弃了所有主流算法，转向2023年由Tennage和Băsescu等人发表的QuePaxa。

问题的根源在于领导者型共识的两个结构性缺陷。第一个是破坏性干扰：当领导者故障或变慢时，多个副本同时发起选举，彼此阻止对方获得多数票，选举反复失败。即使网络故障仅持续两秒，选举风暴可能延续远超故障本身的时间。作者称之为亚稳态故障——初始原因消失后，故障模式仍自我维持。

第二个缺陷是故障检测本身。在异步网络中，一个进程无法直接观察远程进程是否已死，只能观察预期消息是否按时到达。延迟突发和连接中断会让健康的领导者看起来已经故障。Raft通常部署选举超时为网络往返时间的五到十倍，在跨洋链路上百毫秒的往返意味着检测一个失败协调者可能需要接近一秒——这段时间内系统完全停摆。Cloudflare在2020年亲历了这一点：一台核心网络交换机的部分故障导致内部共识系统降级，仪表盘运行速度降为正常的八十分之一，持续六小时，数据未丢失但写入完全不可用。

QuePaxa的应对方式是三项设计选择。第一，领导者变为可选。任何提议者都可以提交提案，领导者只是拥有最高优先级、最可能单程往返完成决策的那个。领导者宕机时，客户端继续向其他提议者发送请求，系统不停。第二，用建设性干扰替代破坏性干扰。提议者不是竞争各自的提案，而是通过随机优先级协作收敛到已知最高优先级的提案——当提议者收到更高优先级的提案时，它采纳该提案而非与之对抗。第三，对冲超时不受网络延迟约束。客户端向所有副本发送请求，非领导者副本等待一个很短的本地超时后自行提案。这个超时不是故障检测，不需要大于网络往返时间，因此可以设得极小而不冻结系统。

具体执行分为四个阶段。阶段零中，提议者随机选择优先级并提交，采纳从多数记录器收到的最高优先级提案；如果领导者确认其提案先到达多数记录器，可立即决策。阶段一将采纳的提案扩散到多数记录器。阶段二让提议者查询多数记录器在阶段一中看到的最高优先级提案，若与自身一致则决策。阶段三为未能决策的提议者准备下一轮，从多数记录器采纳最佳提案。多数交集性质保证安全：任意两个多数集合至少共享一个记录器，因此已决策的提案不可能被后续轮次推翻。

Cloudflare报告了内部评估结果：在服务器横跨几乎所有大洲的环境中，Meerkat持续处理请求，从未完全停摆。正常情况下95%以上的决策在阶段零由领导者单程完成；领导者故障时决策率降至约65%，一分钟后替换领导者即恢复。当决策未在阶段零完成时，吞吐短暂降至正常值的三分之一，因为需要三个往返而非一个。作者强调这是权衡而非免费午餐：更多活跃提议者意味着更多广播和更低的单轮决策概率，但他们认为用带宽换取不中断是值得的。

需要保留的边界：QuePaxa论文预测每轮有50%的决策概率，实际因收敛效应更高，但没有保证的轮数上界。Cloudflare的性能数据为内部自报，且算法本身未经Raft或Paxos同等规模的独立实战检验。作者也提到正在将原始crash-stop设计扩展为支持crash-recovery，这增加了工程复杂性和正确性验证需求。

对读者的实际意义：如果你的共识系统运行在可预测延迟的局域网中，Raft仍然是正确选择。但如果你的副本跨越大洲、网络延迟不可预测且故障检测误判的代价是系统停摆，QuePaxa的可选领导者和建设性干扰机制提供了一个有具体设计理由和初步生产证据的替代路径。核心洞察不是QuePaxa比Raft更快，而是它在网络恶化时不会完全停止——当网络正常时它快，当网络不正常时它仍在推进。