关于多paxos的几个问题？

Question

我有几个关于多paxos的问题

1. 每个实例都有它自己的提案编号和接受的投票和接受的价值吗？或者所有实例共享相同的内容 提案编号，一个完成后，然后另一个开始？

2. 如果所有实例共享具有相同的提议编号，请考虑以下条件，服务器A发送提议，并且接受方返回可能大于或小于提议的实例ID的接受的instanceId，然后提案会做什么？使用该instanceId及其接受阶段的值？然后增加它自己的instanceId，等待下一轮，然后用自己的值重新提议？如果是，删除之前接受的值是什么时候，因为如果它没有被删除，接受者将再次返回此intanceId和值，那么它似乎是一个循环

Answer 1

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

方法＃1 - “否”

Mindset：Paxos是用于构建一次写入寄存器的两阶段协议。 Multi-Paxos是一种如何在它们之上创建日志的技术。

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

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

2. 在新纪录上我们应该：

   A）猜测一个空置寄存器的索引（X）并尝试在此处写一个虚拟记录（如果已经使用过，那么选择一个索引更高的寄存器并重试）。

   B）开始向每个小于X索引的寄存器写入虚拟记录，直到我们找到一个填充了非虚拟记录的寄存器。

   C）基于它计算新记录（例如，记录可能有序数，我们可以用它来计算新记录的序数;因为有些寄存器填充了虚拟记录，所以序数不相等索引）并将其写入X+1寄存器。如果发生冲突，我们应该从步骤A)重启该程序。

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

当然，这种方法有很多开销，所以请像对顶级概述一样对待Multi-Paxos。

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

方法＃2 - “是”

Mindset：可重写寄存器是Multi-Paxos的高度优化版本。

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

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

我在How Paxos Works帖子中描述了这种方法，并在Gryadka项目中使用500行JavaScript实现了该方法。此外，它背后的想法是通过Greg Rogers和Tobias Schottdorf与TLA +进行独立检查。