基于 Paxos 的复制键值存储的领导者选举答案

【问题标题】：Leader election for paxos-based replicated key value store基于 Paxos 的复制键值存储的领导者选举
【发布时间】：2014-05-02 16:55:10
【问题描述】：

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

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

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

感谢您的任何回答。

【问题讨论】：

【解决方案1】：

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

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

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

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

从纸面上看这两种协议，Raft 协议可以比 Multi-Paxos 具有更好的吞吐量。 Raft 作者（和其他人）认为 Raft 更容易理解和实现。

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

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

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

【讨论】：

我不知道 Raft 协议是什么，所以我不得不查一下。 “Raft 是一种旨在易于理解的共识算法。它在容错性和性能上与 Paxos 相当。不同之处在于它被分解为相对独立的子问题，并且干净地解决了实际系统所需的所有主要部分。” raftconsensus.github.io
@michael“每个共识协议都可以永远循环”的信息源在哪里？
@PatrickChan Fischer、Lynch 和 Patterson 证明了这一点。它通常被称为 FLP 不可能结果。
@michael谢谢。描述 FLP 不可能结果的Impossibility of Distributed Consensus with One Faulty Process 论文并未在论文中证明所有定理都是正确的。我评论了为什么在 rystsov 在this post 的回答中没有证明这些定理是正确的。
@PatrickChan 我同意 rystov 的评论，即讨论应该转到 cs.stackexchange.com。这绝对不应该是两个不同答案的战斗。

【解决方案2】：

您可以使用并行的 multi-paxos 实例来管理集群的配置来解决这个问题。考虑一个通过 multi-paxos 更新的复制 JSON 对象包含以下信息：

您可以使用现有的 paxos 实现并将所有必要的逻辑放在您的网络层中：

【讨论】：