问题描述
我已经很了解Raft是什么，并在MIT6.824 distributed system中实现了它。我还知道什么是paxos的基本功能，我还没有实现此功能，所以我无法掌握所有细节。对于Multi-Paoxs，我感到更加困惑，即，为什么它可以消除很多Prepare RPC？我知道答案应该是Multi-paxos可以有一个固定的领导者，以及来自其他同行的noMoreAccepted响应，以确定是否减少Prepare RPC。但是，我无法详细了解它的原因和作用
我想获得更多一些建议，文章，示例代码或任何对 Multi-paxos 有用的东西，
- 我已经读过
paxos made live和paxos made simple，这两篇论文可以使我对paxos的含义及其工作原理有一个基本的认识。 - 我也看过https://www.youtube.com/watch?v=YbZ3zDzDnrw&t=3035s&ab_channel=DiegoOngaro次，这是一次很棒的演讲，但其中并没有涉及太多细节
解决方法
要回答您的特定问题：
为什么它可以消除很多Prepare RPC？
在论文Paxos Made Simple第10页中说：
新选择的领导者对无数共识算法实例执行第1阶段-在上述情况下，对于实例135-137和所有大于139的实例。
这就是说，如果领导者使用投票号Prepare(135,n)广播了{135}是实例135的准备，则可以将其定义为适用于> = 135的所有实例，这是有效的尚未解决。我们可以推断，对于任何节点来说，“垃圾邮件发送”准备为日志流中无限数量的未固定位置准备消息是安全的。这是因为对于每个职位，每个接受者都对该职位使用Paxos规则。我们可以将准备消息的无限集合压缩为适用于所有较高的未固定职位的单个消息。然后，我们消除了一个稳定领导者任职的准备信息。因此，这是极好的优化。
您询问了任何示例代码。我在Scala中使用函数式编程编写了一个多用户的实现，旨在实现Paxos Made Simple上的论文https://github.com/trex-paxos/trex。核心状态为PaxosData，消息协议位于PaxosProtcol的底部，算法是PaxosAlgorithm中的一组消息匹配函数。该算法将当前不可变状态和不可变消息作为输入，并输出该节点的下一个不可变状态。常见行为被编写为具有完整单元测试的部分功能。这些部分功能由领导者，关注者和候选领导者使用的完整功能组成。在this blog上有一篇文章。
由于优化可以加快日志复制，因此它会将其他消息添加到基本集中。这些涉及Lamport在其论文中未涉及的一些实现细节。一个示例是使用否定确认在节点之间传递信息，以避免由于节点和领导者之间只有一个失败的网络链接而中断稳定的领导者。 TRex尝试将这些功能保持在最低水平，以创建基本但完整的解决方案。
关于Multi-Paxos的答案可能对您有所帮助，该答案讨论了为何将Multi-Paxos称为https://stackoverflow.com/a/26619261/329496
关于原始Part-Time Parliament论文如何使用领导者，还描述了运行多Paxos https://stackoverflow.com/a/46012211/329496的稳定领导者
最后，您可能会喜欢我对The Trial Of Paxos Algorithm发表的Paxos的辩护。