C 系统生成器的paxos

为什么文件中要求领导人选举的单独阶段，而不是领导人选举的准备阶段？与使用隐式准备阶段相比，此附加阶段提供了哪些优势？

您认为不需要在Paxos中实现特定的领导人选举算法是正确的，如中所述。你只需在看到领导者的进步时随机超时，一个稳定的领导者就会出现。不需要其他任何东西，您只需重新发送消息，并在一条引线上超时，然后发出一个Prepare命令。我详细描述了这一点

然而，您可以选择使用您喜欢的自定义领导人选举机制，例如

在这里你可以证明不会有无休止的领袖决斗

一个优化了平均恢复时间

一个经过优化以确保在一定时间内恢复

一个为简单和最少的代码而优化

这里的关键点是，您可以优化故障检测的速度，以及客户端在发生故障后体验实时系统的速度。如果你有快速的故障检测，你的平均恢复时间会更低。如果无法进行领导决斗，这将帮助您确保系统在一定时间范围内恢复（例如，消息往返次数）

国家：

帕克索斯只有在其领导人选举协议中才是活生生的

确认挑选领导人选举协议的重要性，以确保活力。他们还问：

[Paxos实现]能保证什么样的活性属性

也

我们还揭示了与以下方面有关的重要理论差异： 活力，源于人们如何指定帕克斯的细节； 具体来说，我们的重点是领导人选举算法的选择

及

每个领导人选举协议都需要不同程度的稳定性 保持在一个领导者身上（这是保证活力所必需的）

直到论文结束，他们才说：

这些详细信息是构建基于Paxos的高性能、高可用性复制引擎的关键组件

他们把高可用性等同于活力。考虑到随机超时不能保证避免无休止的领导者决斗，他们在一篇论文中被排除在外，因为它试图优化Paxos的活跃度

由于作者没有说明他们为什么选择了领导人选举协议，我们只能猜测他们为什么认为这是最好的。如果我们查看它们的所有图表，它们都与吞吐量相关，而不是平均恢复时间或最大恢复时间。我觉得这令人失望。他们错过了一次机会，在报纸上分享他们的见解，为什么他们选择了他们所选择的确切的领导人选举协议。他们可以使用类似的方法在网络分区和崩溃的组合下测试真正的开源数据库。他们本可以提供实验证据，证明在不同类型的崩溃或网络分区情况下，他们的领导人选举算法优于其他选择

第3节对他们的想法给出了强烈的暗示：

我们观察到，有一个规模的网络稳定性要求 对于整个系统，直接由领导者的选择产生 选举议定书。每一个领导人选举协议都要求不同的 保持单个领导者的稳定性水平（需要 （保证活力）

他们还说：

强大的L1要求即使在面临困难的情况下也能取得进展 （迅速）改变多数。我们相信没有类似Paxos的算法 将能够满足这一要求。如果多数人也改变立场 很快，它可能永远不会稳定足够长的时间来完成任务 领导人选举协议

因此，他们讨论了网络稳定性和崩溃稳定性，以及不同的领导人选举算法如何根据不稳定性的类型执行不同的操作。他们明确地说，没有Paxos算法能够提供快速移动分区的活力。因此，他们含蓄地说，他们正在合理稳定的网络分区下优化活动性

这是一个合理的优化。网络可以也可以做一些奇怪的事情，但不像应用程序进程有磁盘错误、内存错误或bug那样频繁，这些错误会使它们陷入崩溃循环。您希望使用Paxos来确保无论您的网络分区多么疯狂或怪异，您都不会受到损坏。然而，对于领导人选举，您可能会认为网络比其上运行的服务器更稳定。您可能会选择一种领导人选举机制，该机制对于一个进程频繁崩溃和重新启动的相当稳定的网络来说具有快速恢复时间

IMHO实际系统构建者应该默认使用随机超时。随机超时是最简单的事情，可以工作，但他们不能保证他们不会是无休止的领导人决斗。这是不可能的。然而，随机超时在简单性和最少代码方面非常有吸引力，因此不太可能出现错误。这就是Raft算法使用它们的原因。有大量的实用算法本质上是随机的

实际上，您是否能够将随机超时作为最简单的事情来使用取决于您的用例。使用强一致性算法仅复制元数据而不是主数据是一个非常典型的用例。有许多最终一致的系统依赖于强一致的配置，但具有高性能的直接写入。因此，通常可以在Paxos leader崩溃的情况下构建系统，但系统仍在运行，并接受不同保证的读写操作。对于这样的系统，在领导人选举中使用简单的随机超时，并进行指数级后退，可能“足够好”。是高性能强一致性e的一个示例