为什么在论文Paxos for System Builders: An Overview中需要单独的领导选举阶段,而不是使用准备阶段进行领导选举?与使用隐式准备阶段相比,这个附加阶段提供了哪些优势?
1 回答
您是正确的,没有任何需要在 Paxos 中实现特定的领导者选举算法,如Paxos Made Simple中所述。你只需要在看到领导者的进展时随机化超时,就会出现一个稳定的领导者。不需要其他任何东西,您只需在领导者上重新发送消息和超时,然后发出 Prepare。我在这里详细描述。
然而,您可以选择使用您喜欢的自定义领导人选举机制,例如
- 一个你可以证明不会有无休止的领袖决斗的地方
- 一种针对平均恢复时间进行了优化
- 一种经过优化以确保在限定时间内恢复
- 一种针对简单性和最少代码进行了优化
这里的关键点是您可以优化故障检测的速度以及客户在故障后体验实时系统的速度。如果您有快速故障检测,您的平均恢复时间会更短。如果无法进行领导者决斗,这将帮助您保证系统在某个时间限制内恢复(例如,消息往返次数)。
Paxos 与其领导人选举协议一样有效
确认选择领导者选举协议以确保活跃性的重要性。他们还问:
[a Paxos 实施] 保证了哪些活性属性?
还
我们还揭示了与活性相关的重要理论差异,这些差异源于人们如何指定 Paxos 的细节;具体来说,我们的重点是领导选举算法的选择
和
每个领导者选举协议都需要不同级别的稳定性才能保持在单个领导者上(这是保证活跃度所必需的)。
直到论文结尾他们才说:
这些细节是构建高性能、高可用的基于 Paxos 的复制引擎的关键组件。
他们将高可用性等同于活跃度。鉴于随机超时不能保证避免无休止的领导者决斗,因此在试图优化 Paxos 活跃度的论文中有效地排除了它们。
由于作者没有说明他们为什么选择领导选举协议,我们只能猜测他们认为最好的原因。如果我们查看他们的所有图表,它们都与吞吐量相关,而不是平均恢复时间或最大恢复时间。我觉得这很令人失望。他们错过了在论文中分享他们为什么选择他们所做的确切领导人选举协议的见解的机会。他们本可以使用jepsen 之类的东西,在网络分区和崩溃的组合下测试真正的开源数据库。然后,他们本可以提供实验证据,证明他们的领导者选举算法比不同类型的崩溃或网络分区下的替代方案更好。
第 3 节对他们的想法给出了强有力的暗示:
我们观察到对整个系统的网络稳定性要求有一定规模,这直接来自于领导者选举协议的选择。每个领导者选举协议都需要不同级别的稳定性才能保持在单个领导者上(这是保证活跃度所必需的)
他们还说:
强大的 L1 要求即使面对(迅速)变化的多数,也要取得进展。我们相信没有任何类似 Paxos 的算法能够满足这个要求。如果多数人变化得太快,那么它可能永远不会稳定到足以完成领导者选举协议的时间。
因此,他们讨论了网络稳定性和崩溃稳定性,以及不同的领导人选举算法如何根据不稳定性的类型表现出不同的表现。他们明确表示,没有任何 Paxos 算法能够通过快速移动的分区来提供活力。因此,他们含蓄地说,他们正在针对相当稳定的网络分区下的活跃度进行优化。
这是一个合理的优化。网络可以并且做一些奇怪的事情,但不像应用程序进程出现磁盘错误、内存错误或错误那样频繁,这些错误会使它们陷入崩溃循环。您想使用 Paxos 确保无论您的网络分区多么疯狂或怪异,您都不会出现损坏。然而,对于领导人选举,您可能会假设网络比运行在其上的服务器更稳定。您可能会选择一种具有快速恢复时间的领导者选举机制,以用于进程经常崩溃和重新启动的相当稳定的网络。
恕我直言,实用的系统构建者应该默认使用随机超时。随机超时是可以工作的最简单的事情,但它们不能保证它们不会是无休止的领导者决斗。这是不可能的。然而,随机超时在简单性和最少代码方面非常有吸引力,因此不太可能出现错误。这就是 Raft 算法使用它们的原因。有大量实用的算法本质上是随机的。
实际上,您是否可以将随机超时作为最简单的工作取决于您的用例。使用强一致性算法只复制元数据而不是主数据是一个非常典型的用例。有许多最终一致的系统依赖于强一致的配置,但具有高性能的直接写入。因此,通常可以构建 Paxos 领导者已经崩溃但系统仍在运行并接受具有不同保证的读取或写入的系统。对于这样的系统,使用简单的随机超时进行具有指数退避的领导者选举可能“足够好”。科孚岛是一个高性能强一致性引擎的例子,它使用 Paxos 来维护将哪些写入范围复制到哪些节点的映射。然而,客户端使用链复制直接写入多个节点,而不是通过领导者。只有当每个节点都有一致的集群成员视图时,才能保证它是正确的。然而,通过 Paxos 的变化缓慢,并且在 Paxos 领导者选举期间大量的 Corfu 写入可能会继续,因此随机超时可能就足够了。
有人可以说“好吧,如果我可以使用自定义领导人选举来更快地恢复,那么我会的”。然而,这种自定义机制需要编写和调试更多代码。所以我想说,如果你可以忍受随机超时而不是复杂的领导者选举机制,那么你可能应该这样做。