选择 QuePaxa：一种非比寻常的共识算法
内容提要
Cloudflare 为全球控制平面 Meerkat 选用 QuePaxa 共识算法。传统 Raft、Paxos 依赖单一领导者，在广域网延迟波动时易停滞，领导者选举还会带来破坏性干扰和误判故障。QuePaxa 采用可选领导者、随机优先级和提议者协作收敛，无需故障检测即可持续运行。实测中领导者故障时系统仅降速不中断，多数请求仍由领导者单轮完成。Cloudflare 正对其 Rust 实现进行形式化验证。
延伸解读
为何传统共识算法在广域网中易失效
文章指出，Raft、Paxos 等依赖单一领导者的算法在广域网中面临两大问题：领导者故障或延迟升高时系统停滞，以及领导者选举中的破坏性干扰和误判故障。Cloudflare 曾因核心交换机部分故障导致共识系统写入不可用六小时，仪表盘操作慢80倍。这说明在跨洲网络中，网络问题比服务器故障更常见，传统算法难以应对。
QuePaxa 如何实现无故障检测的持续运行
QuePaxa 通过可选领导者、随机优先级和提议者协作收敛来避免依赖故障检测。领导者拥有最高优先级，可单轮完成决策；非领导者提议者收到更高优先级提案时会采纳并传播，从而合作而非竞争。客户端对冲超时仅增加活跃提议者数量，不受网络延迟约束。因此领导者故障时系统仅降速，不会完全停滞。
实测表现与权衡
在 Meerkat 的全球部署中，超过95%的决策由领导者在第一阶段完成，保持吞吐稳定。领导者故障时决策率降至约65%，替换后恢复，系统从未完全停滞。但 QuePaxa 并非没有代价：对冲超时越短，反应越快，但广播提案越多，带宽成本越高，且可能增加决策轮次。这是 Cloudflare 愿意接受的权衡。
采用新算法的风险与验证措施
QuePaxa 尚未像 Raft 或 Paxos 那样经过广泛实战检验，且 Cloudflare 正在将原始崩溃停止设计扩展为支持崩溃恢复，这需要谨慎工程和更强正确性证据。为此，他们正对 QuePaxa 的 Rust 实现和 Meerkat 整体进行形式化验证，并结合模拟与故障注入测试。读者应关注其后续验证结果和基准测试，以评估生产可用性。
Q&A
Cloudflare 为什么选择 QuePaxa 而不是 Raft 或 Paxos？
因为 Meerkat 运行在全球广域网上，网络延迟波动大。Raft、Paxos 等传统算法依赖单一领导者，领导者故障或网络变慢时系统会停滞，且领导者选举会带来破坏性干扰和误判故障。QuePaxa 采用可选领导者、随机优先级和提议者协作收敛，无需故障检测即可持续运行，更适合这种环境。
QuePaxa 是如何避免传统共识算法中的破坏性干扰的？
QuePaxa 让提议者协作而非竞争：每个提议被赋予随机优先级，提议者收到更高优先级的提议时会采纳并广播它，从而共同收敛到最高优先级的提议。这样提议者不会互相无限阻塞，即使没有领导者也能继续推进。
QuePaxa 为什么不需要故障检测？
因为 QuePaxa 中任何提议者都可以提议，领导者只是可选角色。客户端将请求发送给所有副本，非领导者副本会等待一个短暂的对冲超时，让领导者有机会单轮决定。如果领导者故障，其他提议者可以继续提议，系统无需检测领导者是否失败就能继续运行。
QuePaxa 的一轮共识包含哪些阶段？
QuePaxa 的一轮包含四个阶段：阶段0（提议与采纳）：提议者随机选择优先级并发送提议，采纳从多数记录器收到的最高优先级提议；阶段1（传播）：将采纳的提议传播给多数记录器；阶段2（检查与决定）：询问多数记录器上一阶段看到的最高优先级提议，若与自己的采纳提议一致则决定；阶段3（结转）：未决定的提议者采纳多数记录器看到的最佳提议，为下一轮做准备。
QuePaxa 在领导者故障时的实际表现如何？
在 Cloudflare 的测试中，领导者故障时系统不会完全停滞，决策速率会下降到约原来的65%，但在故障领导者被替换后一分钟内恢复到100%。大多数决策（超过95%）仍由领导者在第一阶段单轮完成，系统只会暂时降速而不会中断。
QuePaxa 的领导者与 Raft 的领导者有什么不同？
QuePaxa 的领导者是可选的，不是唯一的提议者，任何提议者都可以提议。领导者拥有最高优先级，可以单轮快速决定，但即使领导者故障，其他提议者也能继续推进。而 Raft 的领导者是必需的，一旦故障系统必须选举新领导者，期间无法处理请求。
Cloudflare 如何确保 QuePaxa 实现的正确性？
Cloudflare 正在对 QuePaxa 的 Rust 实现和整个 Meerkat 系统进行形式化验证，同时进行广泛的模拟和故障注入测试。他们还扩展了原始崩溃停止设计以支持崩溃恢复，并计划发布关于验证、测试和基准测试的后续文章。
