并行 Paxos 实例运行的竞争条件答案

【问题标题】：Race conditions on parallel Paxos instances running并行 Paxos 实例运行的竞争条件
【发布时间】：2014-10-17 04:10:09
【问题描述】：

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

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

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

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

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

然而，

给定 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”？
所以我猜在Paxos的实际应用中，不允许并行Paxos实例？如果是这样，如何避免并行Paxos实例，如果我们允许多个客户端和多个提议者，我们似乎仍然需要一个中心化服务器来标记是否有Paxos在运行。
另外，我对提议者编号有疑问。我在互联网上搜索并声称以下内容
是一个解决方案： 5 个服务器，给定相应的索引 k(0-4)，每个服务器使用数字 5*i + k 来表示该服务器的第“i”个提案。

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

【问题讨论】：

标签： distributed race-condition paxos

【解决方案1】：

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

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

如果节点在网络分区期间分离，您可能会很幸运，并且它是一个干净且稳定的分区，它只会导致多数，它将获得一个新的稳定领导者。如果您获得不稳定的分区或一些丢弃的方向数据包，使得两个或节点开始是“Dueling Leaders”，那么您可以使用随机超时和自适应退避，以最小化试图同时选择的两个节点导致失败的轮次和浪费的消息。客户端将浪费重定向、错误或超时，并将在决斗期间扫描领导者，直到它被解决为稳定的领导者。

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

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

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

【讨论】：

所以你的意思是实际上只有领导提议者负责提议客户的请求，从而避免多个paxos实例同时运行？
我仍然对提案编号感到困惑。您的提案编号解决方案似乎与我列出的类似，不同的提案者使用不同的编号空间，这只是保证后一个编号在同一节点中更大。但是，这不足以保证后面的提案在不同节点上具有更大的数量，正如我在问题中解释的那样。
任何节点都可以通过提出成功的提案提升为领导者，这是成为领导者所必需的；但可能很贵。如果所有节点都在 10 毫秒内超时，那么所有节点都会同时提出建议，这将是一场大战，只有一个节点可以获胜。让每个节点在 rand()*60s 超时，那么你可能不会有领导权之争；但在新的候选领导者提议之前，平均需要等待几秒钟的随机延迟。
这是提案gist.github.com/anonymous/5805c5708c41de3f0311的位打包代码，如果您运行，您可以看到它创建了交错数字。使用该编号，您可以提取计数器，将其递增，然后使用当前服务器编号创建一个新提案。一个不太有效的方法是“counter * 100 + serverId”，假设 serverId 从 0 到 99 运行。或者你可以只使用一个字节来进行位打包。
@user3745804 这个简短的动画幻灯片放映鞋领导者超时和指法领导者。它取自 raft 论文，它使用非常类似于基本 Paxos 的东西来进行领导者提议和选举，但是关于超时和多个冲突提议的想法与基本 Paxos 相同，因此它很好地表明了它很昂贵，所以你想要随机超时。 thesecretlivesofdata.com/raft

【解决方案2】：

但是它的提案数量更大。

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

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

【讨论】：

但是最大的不是最后一个提出的，这不符合paxos的要求。
"*但最大的数字并不完全是最后一个提议的 *" - 正确。我从没说过。
你的意思是这不是必需的？您对我的其他困惑有何看法，例如同时运行多个 paxos 实例？现实世界如何使用paxos算法？
背后的数据模型是状态机。 Paxos 旨在就特定转换是否是应用于该状态机的下一个（或不）达成共识。当且仅当算法达成共识时，所有相关方都会进行相同的转换。假设所有各方都知道相同的先前状态S[N]，那么在应用转换 T 之后的以下状态S[N+1] 也将是：S[N+1] = S[N] + T。鉴于所有各方在启动时都了解了 Lamport 所说的“当前法律状态”并从那时起继续，一切都会好起来的。