我将使用多个 Paxos 实现一个键值存储。我会有几个节点，其中一个是主节点。该主节点接收更新请求并将值复制到从节点。
我的问题是如何选择主节点（或领导者）？我还可以使用Paxos算法吗？如果是这样，您认为有必要将paxos实现抽象为一个单元，不仅可以供复制单元使用，还可以供领导者选举单元使用吗？
如果我使用 id 最小的节点作为领导者？我如何实施主租约？
感谢您的任何答复。
在讨论实际问题之前，我建议，对于类似paxos的系统，你不要将其视为主从关系，而是平等的对等关系。 Basic Paxos 甚至没有领导者的概念。 Multi-paxos 附加一个领导者作为性能优化，选举该领导者是协议的一部分。
Multi-Paxos 归结为下面的 Paxos：有一个准备阶段和一个接受阶段。 Multi-Paxos 的见解是，一旦一个节点赢得了接受轮，它就同时赢得了领导者选举，之后该领导者就不需要准备阶段，直到它检测到另一个节点已接管领导权。
现在一些实用的建议。我在多个 paxos、multi-paxos 和其他共识系统方面拥有多年的工作经验。
我首先建议not实现 Paxos 或 Multi-paxos。优化 Paxos 系统的性能同时保持其正确性非常困难，尤其是当您遇到这些类型的问题时。我会改为研究实现 Raft 协议.
就这两种协议而言，Raft 协议比 Multi-Paxos 具有更好的吞吐量。 Raft 作者（和其他人）认为 Raft 更容易理解和实现。
您还可以考虑使用开源 Raft 系统之一。我没有任何使用它们的经验来告诉你维护起来有多么容易。不过，我听说过维护 Zookeeper 实例的痛苦。 （我也听到过对 Zookeeper 正确性证明的抱怨。）
接下来，已经证明每个共识协议都可以永远循环。在您的系统中构建超时机制，并在适当的情况下进行随机退避。这就是实际工程师解决理论上不可能的问题的方法。
最后，检查您的吞吐量需求。如果您的吞吐量足够高，您将需要弄清楚如何跨多个共识集群进行分区。那是一个完整的“另一个蜡球”。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
