问题标签 [paxos]

我是分布式系统和共识算法的新手。我理解它是如何工作的，但我对一些极端情况感到困惑：当接受者收到一个 ACCEPT 实例但从未听说过最终的共识或决定是什么时，接受者会做出什么反应。例如，提议者在提交期间或在发送所有 ACCEPT 之后正在启动或失败。在这种情况下会发生什么？

谢谢。

为什么在论文Paxos for System Builders: An Overview中需要单独的领导选举阶段，而不是使用准备阶段进行领导选举？与使用隐式准备阶段相比，这个附加阶段提供了哪些优势？

人们在描述 Paxos 时，总是假设集群中已经有一些提议者。但是提议者来自哪里，或者是什么决定了哪些进程成为提议者？

在诸如 PAXOS 和 RAFT 之类的共识算法中，会提出一个值，如果法定人数同意，则将其持久地写入数据存储。在达到法定人数时无法参加的参与者会怎样？他们最终如何赶上？无论我在哪里看，这似乎都留给读者作为练习。

共识算法（例如 raft）要求集群包含奇数个节点以避免裂脑问题。

假设我有一个由 5 个节点组成的集群，如果只有一个节点发生故障会发生什么？集群现在有 4 个节点，这打破了奇数规则，集群会继续正常运行吗？

一种解决方案是再删除一个节点，使集群只包含 3 个节点，但是如果之前发生故障的节点又回来了怎么办？然后集群再次有 4 个节点，我们必须将之前删除的节点带回来以保持集群奇数。

共识算法的实现是否会自动处理这个问题，或者我必须在我的应用程序代码中处理这个问题（例如，删除一个节点）？

我在 wiki 上阅读“paxos”，上面写着：“当多个 Proposer 发送冲突的 Prepare 消息时，或者当 Proposer 没有收到 Quorum of 响应（Promise 或 Accepted）时，轮次失败。在这些情况下，必须开始另一轮具有更高的提案编号。” 但我不明白提案人如何区分其提案未获批准与消息传输需要更多时间？

考虑一个具有 3 个节点的分布式系统 - n1、n2、n3。节点之间有一个共享数据 x。Paxos 在节点上运行。一开始，x 等于 4。

客户端向 n1 发送更新请求，将 x 的值更改为 5。n1 和 n2 通过运行 Paxos 就新值达成共识，但 n3 发生了一些链接故障，因此 n3 没有最新的 x 值。

我们知道 Paxos 提供了强一致性。另一方面，如果客户端向 n1 发送了一个读请求，同时又向 n3 发送了另一个读请求，则返回的值是不一样的（其中一个是 5，另一个是 4）。因此，运行Paxos后，系统并没有强一致性。

我的问题是：我们如何解决这个矛盾？我是不是误会了什么？

在 Datastax 的文档中，他们说 Paxos 协议有四个阶段（意思是在轻量级事务中）：

1. 准备/承诺
2. 阅读/结果
3. 提议/接受
4. 提交/确认

而左侧是提议者的阶段，右侧是接受者的阶段。

然后他们试图解释这个过程：

提议者通过向法定人数的接受者发送包含提议编号的消息来进行准备。如果提案编号是他们收到的最高编号，则每个接受者都承诺接受该提案。一旦提议者收到承诺的法定人数的接受者，就会从每个接受者中读取提议的值并将其发送回提议者。提议者确定要使用的值，并将该值连同提议编号一起提交给法定人数的接受者。当且仅当接受者尚未承诺接受具有高数字的提案时，每个接受者都接受具有特定数字的提案。如果满足所有条件，则该值被提交并确认为 Cassandra 写入操作。

我无法理解这个解释。有人可以更清楚地解释一下吗？

我想证明我对multi-paxos的实现是正确的。有什么有效的例子可供我测试吗？或者可以有其他一些方法来说服其他人我的实现是正确的。

我试图找到一些包含示例的论文，但大多数论文只是指定了算法。

在阅读谷歌关于 chubby 的文章时，我并没有真正理解测序仪的目的

假设我们有 4 个实体：

1. 胖乎乎的细胞
2. 客户 1
3. 客户 2
4. 我们想要使用的服务以及我们将发送请求的位置（我们需要锁定）

据我了解，步骤是：

1. 客户端 1发送lock_request()到Chubby 单元，Chubby 响应Sequencer（假设SequenceNumber = 1）

2. 客户端 1modify_data()使用 Sequencer (SequenceNumber = 1) 向服务发送请求

3. 如果 SequenceNumber 有效（=1），服务会询问Chubby 单元
4. Chubby承认，设置LeasePeriod（锁定到期时间为（假设）60 秒）！在此期间没有人能够获得锁
5. 确认后，Service将有关Client 1 (SequenceNumber = 1)的数据缓存（假设）40 秒

现在：如果客户端 2在我们设置的这 60 秒内尝试获取锁，它将被Chubby 单元拒绝

这意味着客户端 2不可能获取下一个 SequenceNumber = 2 的锁并将任何内容发送到服务

据我了解，SequenceNumber 的所有目的仅适用于当 2 个请求到达Service并且Service可以比较 2 个 SequenceNumber 并拒绝较低的情况，而无需询问Chubby 单元

但是，如果我们有缓存并且不可能在客户端 1持有这个锁的情况下获得客户端 2的锁，这种情况将如何发生？