6

I am going to implement a key value store with multi Paxos. I would have several nodes, one of which is the primary node. This primary node receive update requests and replicate values to slave nodes.

My question is how the primary node (or leader) is selected? Can I still use the Paxos algorithm? If so, do you think it is necessary to abstract the paxos implementation to a single unit that could be used not only by the replication unit but also the leader election unit？</p>

If I use the node with the least id to be the leader? How can I implement the master lease?

Thanks for any answers.

4

2 回答 2

8

在我进入实际问题之前，我建议对于类似 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 正确性证明的抱怨。）

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

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

于 2014-03-26T05:18:31.497 回答
0

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

  • 序列号
  • 当前领导者 ID
  • 当前领导者租约到期的时间戳
  • 对等 ID 列表

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

  • 丢弃从除领导者以外的任何节点收到的所有准备和接受消息，直到租约到期。
  • 在租约到期前不久主动增加序列号和领导者的租约时间。
于 2014-04-09T21:12:23.187 回答