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

【问题标题】：In Paxos, why can't we use random backoff to avoid collision?在 Paxos 中，为什么我们不能使用随机退避来避免碰撞？
【发布时间】：2022-11-02 08:10:53
【问题描述】：

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

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

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

Paxos 算法不断发明 2 阶段算法来解决这个问题。

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

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

【问题讨论】：

【解决方案1】：

您描述的逻辑是在 Raft 中如何实现领导者选举：

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

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

【讨论】：

Andrew，非常感谢您的快速回答和对 Raft 领导者选举阶段的清晰描述。我想这一定是为什么说 Raft 是“比 Paxos 更简单的协议”？
哦，你触动了我的痛点。 Raft 更容易理解！它的设计/编写是为了解决关于日志记录顺序的共识。 Paxos 变得简单是另一回事——它确实允许就单个值达成共识，然后 multipaxos 允许有一个序列——但这绝非易事。我通常推荐以下步骤来学习共识内容： 1. 实现简单的 paxos 2. 实现 multipaxos（这是需要大量阅读的地方） 3. 阅读并尝试做 raft

【解决方案2】：

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

因此，Paxos 是为一般情况而设计的证明共识是总是安全，无论任何消息延迟或碰撞回退。

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

Raft 的设计也具有此保证，因此相同的数学缺陷.

但是，Raft 的作者也做出了专门化 Paxos 的设计选择，以便工程师可以阅读描述并制作一个运行良好的系统。

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

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

重申一下，Paxos 协议被设计成最基本的形式，以便数学家可以证明关于共识的广泛陈述。

笔记：是的，我说 Raft 作者专门研究 Paxos。 Raft 可以映射到更通用的 Vertical Paxos 模型上，而后者又可以映射到 Paxos 模型上。任何实现共识的系统都可以。

【讨论】：