Algorithm 关于multi-paxos的几个问题？

关于multi-paxos，我有几个问题

每个实例是否都有自己的提案编号、接受的选票和接受的价值？或者所有实例都与同一个 方案编号，一个方案完成后，再开始另一个方案

>P>如果所有实例共享相同的建议号，考虑下面的条件，服务器A发送一个建议，并且接收者返回可能大于或小于提议的StistANID的接受的实例ID，那么建议会做什么？在接受阶段使用该实例ID及其值？然后增加它自己的instanceId，等待下一轮，然后用它自己的值重新提议？如果是这样，那么上一个接受的值何时被删除，因为如果它没有被删除，那么接受程序将再次返回这个intanceId和值，那么它似乎是一个循环

---

Multi-Paxos有一个模糊的描述，因此两个人可以基于它构建两个不同的系统，在一个系统的上下文中，答案是“否”，在另一个系统的上下文中，答案是“是”

方法#1-“否” 心态：Paxos是一个用于构建一次写入寄存器的两阶段协议。Multi-Paxos是一种如何在其上创建日志的技术

构建日志的一种可能方法是

创建一个完全独立的一次写入寄存器数组，并用初始值初始化第一个寄存器

根据新的记录，我们应该：

A） 猜测一个空寄存器的索引（

X

），并尝试在此处写入一个虚拟记录（如果它已经被使用，则选择一个索引更高的寄存器，然后重试）

B） 开始将伪记录写入索引小于

X

的每个寄存器，直到找到一个填充了非伪记录的寄存器

C） 基于它计算一个新记录（例如，一个记录可能有一个序号，我们可以使用它来计算新记录的序号；由于一些寄存器中填充了虚拟记录，序号不等于索引），并将其写入

X+1

寄存器。如果发生冲突，我们应该从步骤

a）

重新启动该过程

要读取日志，我们应该从第一条记录开始写入伪值，并且在每次冲突时，我们应该增加索引并重试，直到写入成功，这将表明日志结束

当然，这种方法有很多开销，所以请将其视为多Paxos是什么的顶级概述

日志是一个强大的概念，我们可以将其用作构建分布式状态机的方法——只需将每条记录看作一个更新命令即可。不幸的是，在某些情况下，也有很多开销。例如，如果您想要构建一个键/值存储，并且只关心当前值，而不需要历史记录，并且可能需要实现垃圾收集以从日志中删除过去的版本，从而优化存储成本

方法2——“是” 心态：可重写寄存器作为多Paxos的高度优化版本

如果您从所描述的方法开始，使用一个应用程序来创建键/值存储，然后在其他应用程序中迭代以消除开销，例如，通过动态执行垃圾收集，那么最终您可能会想到如何将一次写入寄存器更新为可重写

在这种情况下，每个实例都使用相同的选票号码，因为所有实例都折叠为一个可重写实例

我在文章中描述了这种方法，并用500行JavaScript在项目中实现了它。此外，它背后的想法由和与TLA+进行了独立检查