据我所知，Paxos 共识算法的核心是任何给定的一组节点中都只有一个“多数”，因此，如果一个提议者被多数人接受，则不可能有另一个多数人接受不同的值，给定任何接受者只能接受 1 个单一值。
因此，共识算法最简单的“幸福路径”就是让任何提议者对大多数接受者进行 ping 操作，看看是否能让他们接受其值，如果可以，我们就完成了。
当并发提议者导致大多数节点无法就某个值达成一致时，就会发生冲突，这可以用最简单的 3 个节点的情况来证明，每个节点都试图让 2 个节点接受其值，但由于并发性，每个节点最终只能让自己“接受”该值，因此没有多数人同意任何事情。
Paxos算法继续发明2阶段算法来解决这个问题。
但是为什么我们不能简单地退后一段随机时间并重试，直到最终一个提议者成功获得多数意见？这可以被证明最终成功，因为每个提议者如果未能获得多数票，都会后退一段随机的时间。
我知道这在性能方面并不理想。但我们首先要考虑性能，只看正确性。我在这里缺少什么吗？这是正确的(基本)共识算法吗？
最佳答案
paxos的设计者首先是一个数学家，他把工程交给了别人。
因此，Paxos 专为一般情况而设计，以证明共识始终安全，无论任何消息延迟或冲突回退。
现在是悲伤的部分。 FLP 不可能性结果是证明，即任何具有此保证的系统都可能会陷入无限循环。
Raft 的设计也是基于这种保证，因此存在相同的数学缺陷。
但是，Raft 的作者还做出了专门化 Paxos 的设计选择，以便工程师可以阅读描述并构建一个运行良好的系统。
这些设计选择之一是常用的指数随机退避技巧，以实用的方式绕过 FLP 结果。这个技巧并没有消除无限循环的数学可能性，但确实使其可能性变得极其、可笑、非常小。
你可以将这个技巧应用到 Paxos 本身，并获得相同的好处(作为专业的 Paxos 维护者，相信我，我们会这样做)，但它不是纯粹的 Paxos。
重申一下，Paxos 协议(protocol)的设计是最基本的形式，以便数学家可以证明有关共识的广泛陈述。任何实际的实现细节都留给工程师。
以下是 RAFT 中的 active 问题导致 6 小时中断的案例:https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/ .
注1:是的，我说Raft作者专门设计了Paxos。 Raft 可以映射到更通用的 Vertical Paxos 模型，而 Vertical Paxos 模型又可以映射到 Paxos 模型。任何实现共识的系统都可以。
注 2:我曾与 Lamport 合作过几次。他非常了解这些工程技巧，并且他认为其他人也都了解。因此，他在论文中重点关注问题的数学，而不是工程。
关于distributed-computing - 在Paxos中，为什么我们不能使用随机退避来避免碰撞？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/74280573/