1

我对使用 Paxos 算法感到困惑。似乎 Paxos 可以用于这样的场景：多个服务器（一个集群，我假设每个服务器都有 3 个角色，proposer、acceptor、leaner）需要保持相同的命令序列以实现一致性和备份。我假设有一些客户端向该服务器发送命令（客户端可能并行发送）。每次命令由一个 Paxos 实例分派到多个服务器时。

  1. 不同的客户端可以向不同的提议者发送不同的命令，对吧？

如果是这样，来自某个客户端的一个命令将引发一个 Paxos 实例。所以，

  1. 多个 Paxos 实例可以同时运行？

如果是这样，client-A 向proposer-A 发送“A += 1”命令，client-B 几乎同时向proposer-B 发送“B += 2”命令，我想看到每个服务器都收到了 2命令，“A += 1”和“B += 2”。

然而，

  1. 给定 5 个服务器，比如 S1-S5，S1 发送命令“A += 1”和 S5 发送命令“B += 1”，S2 承诺 S1 但是 S3，S4 承诺 S5，所以最后 S3、S4、S5 得到“B + = 1" 但 S1,S2 什么都没有，因为承诺的数量不是多数。似乎 Paxos 根本没有帮助。我们在所有 5 台服务器上都没有得到预期的“A += 1”和“B += 2”？

  2. 所以我猜在Paxos的实际应用中，不允许并行Paxos实例？如果是这样，如何避免并行 Paxos 实例，如果我们允许多个客户端和多个提议者，我们似乎仍然需要一个中心化服务器来标记是否有一个 Paxos 正在运行。

  3. 另外，我对提议者编号有疑问。我在互联网上搜索，有人声称以下
    是一个解决方案：5 个服务器，给定相应的索引 k(0-4)，每个服务器使用数字 5*i + k 来表示该服务器的第“i”个提案。

对我来说，这似乎完全不符合要求，因为 server-1 的第一个提案编号始终为 1，而 server-4 的第一个提案编号始终为 4，但是 server-4 可能比 server-1 更早提出提案，但它是提案数字更大。

4

2 回答 2

0

但是它的提案数量更大。

这正是划分提案空间的重点。规则是，只接受最近的提案，即看到的数量最多的提案。因此，如果发出了三个提案，那么只有一个数量最多的提案将获得被接受的多数。

如果你不这样做，多方可能会继续nextNumber = ++highestNumberSeen疯狂地提出带有简单递增数字 () 的提案，并且永远不会达成共识。

于 2014-10-21T13:36:46.643 回答
0

所以我猜在Paxos的实际应用中，不允许并行Paxos实例？如果是这样，如何避免并行 Paxos 实例，如果我们允许多个客户端和多个提议者，我们似乎仍然需要一个中心化服务器来标记是否有一个 Paxos 正在运行。

您不需要集中式服务，只需要节点将客户端重定向到当前领导者。如果他们不知道领导者是谁，他们应该抛出一个错误，并且客户端应该从 DNS/config 中选择另一个节点，直到他们找到或被告知当前领导者。客户端只需要集群中哪些节点的合理最新列表，以便他们可以联系大多数当前节点，然后当它变得稳定时他们会找到领导者。

如果节点在网络分区期间分离，您可能会很幸运，它是一个干净且稳定的分区，只会导致多数，它将获得一个新的稳定领导者。如果您获得了不稳定的分区或一些掉落的方向数据包，以便两个或节点开始成为“决斗领导者”，那么您可以使用随机超时并自适应退缩，以最大程度地减少两个试图在同一时间选举产生失败回合的节点和浪费的消息。客户端将浪费重定向、错误或超时，并将在决斗期间扫描领导者，直到它被解决为稳定的领导者。

paxos 可以有效地从 CAP 中选择 CP，因此它可能会由于领导者决斗或没有多数人能够通信而失去 A（可用性）。也许如果这在实践中确实存在高风险，人们会写下关于让节点将任何反复尝试领导但由于持续不稳定的网络分区问题而永远无法提交的节点列入黑名单。务实地，人们可以想象监视系统的人会收到警报并杀死这样的节点并修复网络，然后再尝试将复杂的“无人看管的工作”功能添加到他们的协议中。

关于提案的数量，一个简单的方案是 64 位长，32 位计数器打包到最高位，32 位节点的 IP 地址打包到最低位。这使得所有数字都是唯一且交错的，并且仅假设您不在同一台机器上运行多个节点。

如果您查看 Wikipedia 上的 Multi-Paxos，它是关于为稳定的领导者优化流程。故障转移应该很少见，所以一旦你得到一个领导者，它就可以只接受消息并跳过提案。如果您将领导者身份打包到事件编号中，那么当您疾驰时，节点可以看到后续接受来自同一领导者并且对于该领导者是连续的。与稳定的领导者一起奔跑是一个很好的优化，并且使用提案创建一个新的领导者是一件昂贵的事情，需要提案消息和决斗领导者的风险，因此除非是集群启动或故障转移，否则应该避免。

于 2014-10-21T16:49:21.480 回答