挑战传统的一致性算法

我们以一种批判性的态度对待了传统观点：认为像 Paxos 和 Raft 这样的算法是构建一致性系统的基础。这种观点似乎暗示其他算法只是原有算法的变体。但从历史角度来看，这些算法确实具有重要的“基础性”，但从概念角度看，它们并不真正具有绝对的基础性。
同时，我们也指出这些算法过于僵化。我认为它们难以适应云部署日益增长的复杂性。FlexPaxos 是第一个重大进展，它表明多数法定人数只是交集法定人数的一种特殊情况。而交集法定人数允许你配置系统时拥有更多灵活性。

一致性系统的新概念化

在这个系列中，我们尝试以以下方式重新定义一致性系统的其他部分：

插件化的持久性

一致性系统可以设计为不依赖固定的持久性规则。这些规则可以通过插件指定，同时系统能够在不破坏完整性的前提下满足这些要求。当然，这些要求需要是合理的。在第3部分中，我们讨论了一些具体的例子。
支持插件化持久性的系统允许你在不显著影响性能特征的情况下扩展额外节点。例如，如果你指定了跨区域的持久性要求，那么向某个区域部署额外节点不会显著改变系统的行为方式。

撤销与建立领导权

我们将领导权变更重新定义为一个两步过程：撤销和建立。交集法定人数只是实现这一目标的众多方法之一。我们展示了通过直接要求当前领导者下台来完成领导权变更的场景。在这种情况下，接下来需要做的就是完成所有必要步骤以建立新的领导权。这种方法不需要了解交集法定人数。
我们还展示了可以使用多种方法变更领导权，且这些方法是互操作的。例如，可以在计划的变更中使用直接领导降级，但在系统发生故障时退回使用交集法定人数。

应对竞争条件

我们讨论了两种截然不同的处理竞争条件的方法：基于锁的和无锁的。这两者的实现方式和权衡非常不同。通常来说，无锁的方法（如 Paxos）具有优雅性，因为它不涉及时间组件。然而，基于锁的方法提供了其他诸多灵活性，在现实场景中占据了优势。使用基于锁的方法，你可以：

  • 请求当前领导者下台，从而执行平滑的领导权变更。
  • （虽然我们没具体讨论这一主题）更容易在系统中添加或移除节点。
  • 将读取请求重定向到当前领导者，从而实现一致性读取。
  • 实现防抖规则（anti-flapping rules）。

由于这些优势，大规模系统几乎都采用基于锁的方法。

完成和传播请求

我们研究了传播请求的边界情况，并建议通过决策版本化来避免因多个部分失败而引发混淆。在 Paxos 中，提案编号用于决策版本化；在 Raft 中，领导任期编号实现类似功能。
我们还展示了许多故障模式可以通过防抖规则完全避免。

Vitess 的实现

在 Vitess 中，我们充分利用了上述方法和灵活性。例如，持久性规则在 vtorc 中实现为插件。当前的插件 API 已经比其他现有实现更强大。你可以指定跨区域或跨地域的持久性要求，而无需精心平衡所有节点的位置分布。
此外，Vitess 具有平滑故障转移机制，可用于软件部署。这些自动化功能作为 Vitess Operator 的一部分内置。
Vitess 允许你将读取请求指向当前领导者，从而实现一致性读取。
目前仍存在一些需要人工干预的边界情况。我们计划增强 vtorc，以解决这些复杂场景。这将使 Vitess 实现完全自动化。

最后的总结

仍有一些值得探讨的主题：

  • 故障检测
  • 一致性读取
  • 添加和移除节点

严格来说，这些主题超出了一致性算法的范围，但它们需要在实际部署中加以解决。我可能会在之后发布独立的文章来探讨这些内容。
一致性算法也许可以通过另一组规则进行进一步概括。但我个人认为，本系列中提出的概念化方法是最易于理解的一种。


在大规模场景中实现一致性算法：第8部分 – 总结思考插图

关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台

除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接

本文链接：http://www.choupangxia.com/2025/09/07/consensus-algorithms-at-scale/