在诸如PAXOS和RAFT之类的共识算法中，提出了一个值，并且如果仲裁同意，则将其持久地写入数据存储中。仲裁时无法使用的参与者会如何处理？他们最终如何赶上？无论我在哪里看，这似乎都是读者的练习。
答案 0 :(得分：1)
看看Raft协议。它只是内置在算法中。如果领导者跟踪要发送给每个关注者的最高索引（matchIndex）和nextIndex，并且领导者始终从该关注者的nextIndex开始向每个关注者发送条目，需要特殊情况来处理追随条目提交时丢失的追随者。从本质上讲，重新启动时，领导者将始终开始从其日志中的最后一个条目开始向该跟随者发送条目。因此，该节点被捕获。
答案 1 :(得分：0)
对于Paxos的原始论文，确实是留给读者的练习。在实践中，使用Paxos，您可以发送其他消息（例如否定确认）来优化性能，从而在群集周围传播更多信息。这可以用来让节点知道由于消息丢失而导致其落后。一旦节点知道它在后面，就需要跟上，这可以使用其他消息类型来完成。在我写给Retransmission的Trex多用户引擎中，它被描述为demystify Paxos。
Google Chubby paxos论文Paxos Made Live批评Paxos将大量精力留给了实施人员。兰珀特接受过数学家的培训，并试图以数学方式证明当他找到解决方案时，您无法就有损网络达成共识。原始论文在很大程度上提供了可能的证明，而不是解释如何用它来构建实际的系统。现代论文通常描述了一些实验结果支持的一些新技术的应用，尽管它们也提供了正式的证明，恕我直言，大多数人都跳过它并信任它。引入Paxos的一种难以接近的方式意味着许多引用原始论文但没有看到他们描述leader election and multi-Paxos的人。不幸的是，Paxos仍然以理论的方式来教授，而不是以现代的方式教授，这使人们认为这很困难而错过了本质。
我认为Paxos is simple，但是很难对分布式系统中的故障进行推理并进行测试以查找任何错误。原始论文中留给读者的所有内容都不会影响正确性，但会影响延迟，吞吐量和代码的复杂性。一旦了解了使Paxos正确的原因（从机械上来说很简单），就可以直接编写所需的其余内容，并且在针对用例和工作负载优化代码时不会破坏一致性。
例如，Corfu和CURP给出了惊人的高性能，其中一个仅将Paxos用于元数据，另一个仅在同时写入相同密钥时才需要执行Paxos。这些解决方案不能解决Raft或Multi-Paxos的问题，因为它们可以解决特定的高性能场景（例如k-v商店）。但是，它们证明了值得理解的是，如果您的特定工作量可以让您在仍将Paxos用作整体解决方案的一部分时，可以对实际应用进行大量优化。
答案 2 :(得分：0)
在Paxos简化中提到了这一点：
由于消息丢失，可以选择一个值而没有学习者发现。学习者可以向接受者询问他们接受了哪些提议，但是接受者的失败可能使得无法知道大多数人是否接受了特定提议。在这种情况下，学习者只有在选择新建议时才能发现选择了什么价值。如果学习者需要知道是否选择了一个值，则可以使用上述算法让提议者发布提议。
还有木筏纸：
领导者为每个关注者维护一个nextIndex，这是领导者将发送给该关注者的下一个日志条目的索引。
如果关注者的日志与领导者的日志不一致，则下一个AppendEntries RPC中的AppendEntries一致性检查将失败。拒绝后，领导者递减nextIndex并重试AppendEntries RPC。最终nextIndex将到达领导者和关注者日志匹配的地步。发生这种情况时，AppendEntries将成功执行，这将删除关注者日志中的所有冲突条目，并从领导者的日志中添加条目（如果有）。
如果关注者或候选者崩溃，则将来发送给它的RequestVote和AppendEntries RPC将失败。 Raft通过无限期重试来处理这些故障；如果崩溃的服务器重新启动，则RPC将成功完成。