在Paxos中，为什么我们不能使用随机退避来避免碰撞呢？

Question

我知道 Paxos 共识算法的核心是在任何给定的一组节点中只有一个“多数”，因此如果提议者被多数接受，则不能有另一个多数接受不同的值，因为任何接受者只能接受 1 个单一值。

因此，共识算法最简单的“快乐路径”就是让任何提议者 ping 多数接受者，看看是否能让他们接受它的价值，如果是的话，我们就完成了。

当并发提议者导致没有大多数节点同意一个值的情况时，就会发生冲突，这可以用最简单的 3 个节点的情况来证明，并且每个节点都试图让 2 个节点接受它的值，但是由于并发性，每个节点最终只会让自己“接受”该值，因此没有多数人同意任何事情。

Paxos 算法继续发明了一种 2-phase 算法来解决这个问题。

但为什么我们不能简单地退避一段随机的时间并重试，直到最终一个提议者成功获得多数意见？ 这可以证明最终会成功，因为如果每个提议者未能获得多数，都会随机退避一段时间。

我知道这在性能方面不会很理想。 但是让我们先把性能排除在外，只看正确性。 我在这里缺少什么吗？ 这是一个正确的（基本的）共识算法吗？

Answer 1

paxos的设计者首先是数学家，他把工程留给别人。

因此，Paxos 是为一般情况而设计的，以证明共识始终是安全的，而不管任何消息延迟或冲突回退。

现在是悲伤的部分。 FLP 不可能的结果证明任何具有此保证的系统都可能陷入死循环。

Raft 的设计也具有这种保证，因此也存在同样的数学缺陷。

但是，Raft 的作者也做出了设计选择以专门化 Paxos，以便工程师可以阅读描述并构建功能良好的系统。

这些设计选择之一是指数随机退避的常用技巧，以实用的方式绕过 FLP 结果。 这个技巧并没有消除无限循环的数学可能性，但确实使它的可能性变得极其可笑、非常小。

你可以把这个技巧应用到 Paxos 本身，并获得同样的好处（作为专业的 Paxos 维护者，相信我，我们这样做），但它不是 Pure Paxos。

重申一下，Paxos 协议被设计为最基本的形式，以便数学家可以证明关于共识的广泛陈述。 任何实际的实施细节都留给工程师。

---

这是 RAFT 中的活性问题导致 6 小时中断的案例：https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/ 。

---

注1：对，我说的是Raft作者专攻Paxos。 Raft 可以映射到更通用的 Vertical Paxos model，后者又可以映射到 Paxos model。任何实现共识的系统都可以。

---

注 2：我曾与 Lamport 合作过几次。 他非常了解这些工程技巧，并且他认为其他人也是如此。 因此，他在论文中专注于问题的数学，而不是工程。

Answer 2

您所描述的逻辑是 Raft 中领导者选举的实现方式：

• 当没有领导者（或领导者下线）时，每个节点都会有一个随机延迟
• 在随机延迟之后，该节点将联系所有其他节点并提议“让我成为领导者”
• 如果该节点获得多数票，则该节点认为自己是领导者：这相当于说“集群就谁是领导者达成了共识”
• 如果该节点没有获得多数，则在超时和随机延迟后，该节点将再次尝试

Raft 也有术语的概念，但在较高的层次上，随机等待是有助于更快达成共识的特性。

回答你的问题“为什么我们不能......” - 我们可以，这将是一个不同的协议。