问题标签 [paxos]

当两个将军证明“设计算法不可能安全地达成一致”时，像Paxos这样的共识算法如何“保证安全（免于不一致） ”？

当我考虑让两台服务器（1）可靠地交换一个号码（即，两台服务器最终都知道对方肯定收到了号码）或（2）两台服务器最终都知道交换失败并且不改变他们的状态，看起来（就像两位将军一样）消息失败总是会以一种不一致的方式发生（即，一个服务器认为另一个完成了交换，但它没有）。

那么 Paxos（或其他任何东西）如何真正保证“免于不一致”？有简单的语言解释吗？演示两台服务器进行有保证的交换或在失败时完全放弃交换的最简单的伪代码是什么？

我对提议者选择的价值感到困惑。用一个例子来解释。如果现在一个提议者想要锁定一个文件，那么它将发送 l1 是处理器编号，v1 是“锁定文件”的值，并且接受者接受它。比提议者要解锁文件，并发送（l2 > l1）v2 是“解锁文件”的值，之后，接受者返回最后一个值，提议者选择它并再次发送。

在这个例子中，v2 丢失了吗？或者这个例子中的真实过程是什么？还有，这是两轮还是一轮？怎么处理圆？

在chubby中，每条日志写入db的进程都是paxos进程的一个实例，而这个实例可能有很多proposer，所以会有一个master选中的进程。为什么它有很多提议者？

据我了解 Chubby 在任何时候都有 5 台 Chubby 服务器。一个是主服务器，负责协调对仲裁的写入，其他 4 个服务器是只读的，并转发处理对主服务器的写入。写入使用 Paxos 来保持一致性。

有人可以向我解释为什么主副本和 4 个副本之间存在区别。为什么 Chubby 不是多主控？这个问题也适用于 Zookeeper。

在收到来自提议者的准备消息后，接受者会以承诺或拒绝进行响应。

如果提议者没有收到足够的承诺和超时，提议者应该丢弃收到的承诺/拒绝，并以更大的选票开始新的准备轮次。

如果重启只是因为超时而不是收到拒绝，我们可以重复使用相同的选票号码吗？

我读了这篇关于 Paxos paxos 价值选择的帖子， 但我仍然不清楚。假设我们第一次运行 Paxos，Proposer 发送 Prepare，Acceptors 回复 (null, null)，因为他们没有学到任何值，所以 Proposer 同意自己的值并将其发送给他们接受的接受者。让我感到困惑的是，当 Proposer 收到 Promise-acks 并需要发送 Accept 消息时：

如果任何 Acceptor 之前接受过任何提案，那么他们将把他们的值发送给 Proposer，Proposer 现在必须将其提案的值设置为与 Acceptor 报告的最高提案编号相关联的值。（来自维基百科）

我不明白——选择“与接受者报告的最高提案编号相关的值”有什么意义？有人可以举个例子来解释一下吗？

我是分布式系统的新手，我正在阅读“简单的 Paxos”。它引起了很多喋喋不休，我正在考虑性能影响。

假设您正在构建一个全球分布的数据库，其中有几个位于不同位置的小型集群。尽量减少跨站点通信的数量似乎很重要。

1. 您绝对需要使用共识的决定是什么？我唯一想到的肯定是决定是否从网络中添加或删除一个节点（或一组节点？）。这似乎是矢量时钟工作所必需的。另一个我不太确定的是决定写入同一位置的顺序，但这应该由通过 Paxos 选举的领导者来完成吗？

2. 避免让系统中的所有节点一起做出决策会很好。每个本地集群中的几个节点是否可以参与跨集群决策，并且所有本地节点都使用本地 Paxos 进行通信以确定跨站点问题的本地答案？假设网络未饱和，延迟将是相同的，但跨站点网络流量会轻得多。

3. 假设您可以沿行拆分数据库的表，并将每个行子集分配给节点子集。使用 Paxos 在系统中的所有机器上选择一组节点来包含每个数据子集，然后只在这些节点之间为处理该数据子集的所有操作运行 Paxos，这是否正常？

还有一个包罗万象：人们是否正在采取其他与设计相关的或算法优化来解决这个问题？

Node_1 是领导者，node_2 意外死亡，Node_1 需要重新运行 Paxos，因为 Paxos 值与当前节点死亡或活着有关。但是只有 1 个节点（node_1 本身）同意这个提议，node_2 不会响应。这个条件不能达到“通过一半的节点同意，即2个节点”。它如何工作？

背景：

在Lamport 的论文Paxos Made Simple的第 3 节，命名为实现状态机，描述了 Multi-Paxos。Google Paxos Made Live中使用了 Multi-Paxos 。（在Apache ZooKeeper中使用了 Multi-Paxos）。在 Multi-Paxos 中，可能会出现间隙：

一般来说，假设一个领导者可以α提前获得命令——也就是说，它可以在命令 1 到命令被选择之后i + 1通过命令提出命令。然后可能会出现最多命令的间隙。i + αiα - 1

现在考虑以下场景：

整个系统采用主从架构。只有 master 服务于客户端命令。Master 和 Slave 通过 Multi-Paxos 就命令的顺序达成共识。master 是 Multi-Paxos 实例中的领导者。假设现在 master 和它的两个 slave 的状态（命令已被选择）如下图所示：

.

请注意，在主状态中存在不止一个间隙。由于不同步，两个奴隶落后。这时候master就失败了。

问题：

1. slave检测到master故障后应该怎么做（比如通过心跳机制）？

2. 特别是与老主控的差距和缺失的命令如何处理？

关于 Zab 的更新：

正如@sbridges 所指出的，ZooKeeper使用Zab而不是 Paxos。去引用，

Zab 主要设计用于主备份（即主从）系统，如 ZooKeeper，而不是用于状态机复制。

Zab 似乎与我上面列出的问题密切相关。根据Zab 的简短概述论文，Zab 协议由两种模式组成：恢复和广播。在恢复模式下，有两个特定的保证：永远不会忘记已提交的消息和放弃已跳过的消息。我对 Zab 的困惑是：

3. 在恢复模式下，Zab 是否也会遇到间隙问题？如果是这样，Zab 做了什么？

我最近一直在对 Paxos 进行大量研究，我一直想知道的一件事是，我没有看到任何答案，这意味着我必须问。

Paxos 包含一个不断增加的提案编号（可能还有一个单独的整数，具体取决于您正在阅读的论文的作者）。当然，两个潜在的领导者可能会陷入决斗，每个人都试图在恶性循环中超越对方。但是当我在拜占庭式 P2P 环境中工作时，这让我如何处理那些试图将提案编号设置得非常高的提案者——例如，最大 32 位或 64 位字。

与语言无关、平台无关的基于 Paxos 的协议应该如何处理提案编号和/或轮数的整数最大值？尤其是故意/恶意的情况，这使得溢出回 0 的模算术方法有点没有吸引力？