有人对 Multi-Paxos 有什么建议吗？
does anyone have any recommendatation for Multi-Paxos?
我已经很明白什么是 Raft 并在 MIT6.824 distributed system 中实现了它。我也知道什么是基本的Paxos，我还没有实现这个，所以我不能抓住它的所有细节。对于Multi-Paoxs，我更加困惑，即为什么它可以消除大量的Prepare RPC？我知道答案应该是 Multi-Paxos 可以有一个固定的领导者以及来自其他节点的 noMoreAccepted 响应来确定是否减少 Prepare RPC。但是，我无法详细了解它，为什么以及如何工作
我想获得更多一些建议、文章、示例代码或任何对Multi-Paxos、[=17 有帮助的 =]
- 我读过
Paxos made live 和 Paxos made simple，这两篇论文可以让我对什么是 Paxos 及其工作原理有一个基本的了解
- 我也https://www.youtube.com/watch?v=YbZ3zDzDnrw&t=3035s&ab_channel=DiegoOngaro看了好几遍，讲得很好，但没有涉及太多细节
回答您的具体问题：
WHY it can eliminate lots of Prepare RPC?
论文 Paxos Made Simple 第 10 页说：
A newly chosen leader executes phase 1 for infinitely many instances of the consensus algorithm—in the scenario above, for instances 135–137 and all instances greater than 139.
也就是说，如果领导者广播 Prepare(135,n) 这是一个准备实例 135 使用选票编号 n 那么这可以定义为适用于所有实例是有效的 >=135尚未修复。我们可以推断，任何节点为我们的日志流中无限数量的未固定位置“发送”准备消息是安全的。这是因为对于每个位置，每个接受者都使用该位置的 Paxos 规则。我们可以将那组无限的准备消息压缩成一个适用于所有更高的未固定位置的消息。然后，我们消除了除一个稳定领导任期的准备消息外的所有消息。所以这是很棒的优化。
您询问了任何示例代码。我在 Scala 中使用函数式编程编写了 multi-paxos 的实现，旨在忠实于 上的论文 Paxos Made Simple https://github.com/trex-paxos/trex 。核心状态是PaxosData，消息协议在PaxosProtcol底层，算法是中的一组消息匹配函数]Paxos算法。该算法将当前不可变状态和不可变消息作为输入，并输出节点的下一个不可变状态。常见行为被编写为具有完整单元测试的部分函数。这些部分功能组合成完整的功能，供领导者、追随者和候选领导者使用。 此博客 上有一篇文章。
它向基本集添加了额外的消息，因为优化加速了日志复制。这些涉及 Lamport 在他的论文中没有涉及的一些实施细节。一个例子是否定确认用于在节点之间传递信息，以避免由于节点和领导者之间只有一个失败的网络 link 而中断稳定的领导者。 TRex 试图将这些功能保持在最低限度，以创建一个基本但完整的解决方案。
关于 Multi-Paxos 您可能会觉得有帮助的一个答案是这个讨论为什么 Multi-Paxos 被称为
的答案
原来还有这个讲的如何Part-Time Parliament paper uses a leader and also describes a stable leader running multi-Paxos
最后，你可能会喜欢我对 Paxos 的辩护 post The Trial Of Paxos Algorithm.
我已经很明白什么是 Raft 并在 MIT6.824 distributed system 中实现了它。我也知道什么是基本的Paxos，我还没有实现这个，所以我不能抓住它的所有细节。对于Multi-Paoxs，我更加困惑，即为什么它可以消除大量的Prepare RPC？我知道答案应该是 Multi-Paxos 可以有一个固定的领导者以及来自其他节点的 noMoreAccepted 响应来确定是否减少 Prepare RPC。但是，我无法详细了解它，为什么以及如何工作
我想获得更多一些建议、文章、示例代码或任何对Multi-Paxos、[=17 有帮助的 =]
- 我读过
Paxos made live和Paxos made simple，这两篇论文可以让我对什么是 Paxos 及其工作原理有一个基本的了解 - 我也https://www.youtube.com/watch?v=YbZ3zDzDnrw&t=3035s&ab_channel=DiegoOngaro看了好几遍，讲得很好，但没有涉及太多细节
回答您的具体问题：
WHY it can eliminate lots of Prepare RPC?
论文 Paxos Made Simple 第 10 页说：
A newly chosen leader executes phase 1 for infinitely many instances of the consensus algorithm—in the scenario above, for instances 135–137 and all instances greater than 139.
也就是说，如果领导者广播 Prepare(135,n) 这是一个准备实例 135 使用选票编号 n 那么这可以定义为适用于所有实例是有效的 >=135尚未修复。我们可以推断，任何节点为我们的日志流中无限数量的未固定位置“发送”准备消息是安全的。这是因为对于每个位置，每个接受者都使用该位置的 Paxos 规则。我们可以将那组无限的准备消息压缩成一个适用于所有更高的未固定位置的消息。然后，我们消除了除一个稳定领导任期的准备消息外的所有消息。所以这是很棒的优化。
您询问了任何示例代码。我在 Scala 中使用函数式编程编写了 multi-paxos 的实现，旨在忠实于 上的论文 Paxos Made Simple https://github.com/trex-paxos/trex 。核心状态是PaxosData，消息协议在PaxosProtcol底层，算法是中的一组消息匹配函数]Paxos算法。该算法将当前不可变状态和不可变消息作为输入，并输出节点的下一个不可变状态。常见行为被编写为具有完整单元测试的部分函数。这些部分功能组合成完整的功能，供领导者、追随者和候选领导者使用。 此博客 上有一篇文章。
它向基本集添加了额外的消息，因为优化加速了日志复制。这些涉及 Lamport 在他的论文中没有涉及的一些实施细节。一个例子是否定确认用于在节点之间传递信息，以避免由于节点和领导者之间只有一个失败的网络 link 而中断稳定的领导者。 TRex 试图将这些功能保持在最低限度，以创建一个基本但完整的解决方案。
关于 Multi-Paxos 您可能会觉得有帮助的一个答案是这个讨论为什么 Multi-Paxos 被称为
的答案原来还有这个讲的如何Part-Time Parliament paper uses a leader and also describes a stable leader running multi-Paxos
最后，你可能会喜欢我对 Paxos 的辩护 post The Trial Of Paxos Algorithm.