distributed-system - 基于 Paxos 的复制键值存储的领导者选举

Question

我将使用多 Paxos 实现键值存储。我会有几个节点，其中一个是主节点。该主节点接收更新请求并将值复制到从节点。

我的问题是如何选择主节点(或领导者)？我还能使用 Paxos 算法吗？如果是这样，您认为有必要将 paxos 实现抽象为一个单元，该单元不仅可以供复制单元使用，还可以供领导选举单元使用？

如果我使用 id 最小的节点作为领导者？如何实现主租约？

感谢您的任何回答。

Answer 1

在我进入实际问题之前，我建议对于类似 paxos 的系统，不要将其视为主从关系，而应将其视为平等对等关系。 Basic Paxos 甚至没有领导者的概念。 Multi-paxos 将领导者作为性能优化，选举领导者是协议(protocol)的一部分。

Multi-Paxos 归结为 Paxos:有一个准备阶段和一个接受阶段。 Multi-Paxos 的见解是，一旦一个节点赢得了接受轮次，它同时赢得了领导选举，之后该领导不需要准备阶段，直到它检测到另一个节点已经接管领导。

现在一些实用的建议。我在多个 paxos、multi-paxos 和其他共识系统上拥有多年的工作经验。

我首先建议不要实现 Paxos 或 Multi-paxos。在保持正确的同时优化 Paxos 系统的性能是非常困难的——尤其是当您遇到这些类型的问题时。我会改为 研究实现 Raft 协议(protocol) .

考虑到这两种协议(protocol)，Raft 协议(protocol)可以比 Multi-Paxos 具有更好的吞吐量。 Raft 作者(和其他人)认为 Raft 更容易理解和实现。

您也可以考虑使用其中一种开源 Raft 系统。我没有使用其中任何一个的经验来告诉你它是多么容易维护。不过，我听说过维护 Zookeeper 实例的痛苦。 (我也听说过关于 Zookeeper 正确性证明的提示。)

接下来，已经证明每个共识协议(protocol)都可以永远循环。在您的系统中构建超时机制，并在适当的情况下随机退避。这就是实际工程师如何绕过理论上的不可能。

最后，检查您的吞吐量需求。如果您的吞吐量足够高，您将需要弄清楚如何跨多个共识集群进行分区。这是一个完整的“另一个蜡球”。