筏算法正常操作

Question

我已经阅读了Raft算法论文并得到了一个与Raft在收到客户请求时执行的操作顺序相关的问题：

为了克服单点故障情况，Raft依赖于在其他计算机上维护复制日志，该算法还参考了共识模块以进行完整的日志记录管理。操作顺序如下：

1. 客户端请求在领导者的状态机中收到，领导者将命令附加到其日志中。
2. 领导者将 AppendEntries RPC发送给其关注者以在其本地日志中克隆该命令，并等待大多数关注者确认该条目已成功附加到其本地日志文件。
3. 一旦收到确认请求已成功记录在大多数关注者日志中，则请求被提交给领导者的状态机，导致转换发生，返回输出转移到客户端。
4. 最终，领导者会在后续的 AppendEntries RPC中通知关注者已提交的条目。

如果上述理解是正确的，那么我可以声称客户端请求被保留一段时间以完成复制过程，我也可以声称客户端请求的成功在很大程度上取决于成功复制过程（因为客户端命令/请求不会在领导者的机器上执行，直到收到多数确认为止）。问题是，在复制过程完成后，客户端请求平均需要多长时间才能收到响应，这对于实时系统是否有效？

Answer 1

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed表明诸如Raft之类的系统要求CAP定理的三位一体的一致性和可用性部分将受到性能限制。您可能还对https://pdfs.semanticscholar.org/7c45/54d064128043897ea2226021f6fda4c64251.pdf（由Birman撰写的可靠多播体验回顾）感兴趣，该报告描述了在高保障系统（如空中交通管制）中使用可靠多播组的经验。

我从中得到的结论是，一个真实的系统可能会非常小心它对Raft，Paxos和朋友保护的信息，以及它可以防范的程度。另一个观点是采用非常复杂的Paxos实现，例如Google Spanner，这样程序员就不必担心非ACID系统的问题。

Answer 2

  

如果上面的理解是正确的，那么我可以声称客户端请求被保留了一段时间，以便复制过程完成

正确的，当前术语的领导者仅在命令已复制到集群中的大多数节点之后才确认客户端请求。

  

我也可能声称客户请求的成功在很大程度上取决于复制过程的成功

那也是正确的。群集中至少大多数节点（包括领导者）都必须可用且具有响应能力，以便成功复制命令并使领导者确认请求。

  

在复制过程完成后，预计客户请求平均需要多长时间才能收到响应

这取决于您的网络拓扑。响应客户端请求的等待时间将由以下部分组成（假设没有领导者崩溃）： *在客户端和领导者之间传输客户端请求所需的等待时间。 *领导者向关注者复制条目的AppendEntries请求的等待时间（与所有关注者并行发送）。 *从关注者到领导者的AppendEntries响应的延迟。 *领导者将命令应用于其状态机所需的时间（即最佳情况下的磁盘写入） *客户端响应从领导者传输到客户端的延迟时间

各种消息的等待时间取决于节点之间的距离，但是可能在十分之一到几百毫秒之间。

  

这对于实时系统也有效吗？

这取决于您对特定案例的要求。但是总的来说，实时系统要求的延迟在几毫秒以下，因此答案很可能不是。另外，请记住，在发生新领导人选举的崩溃和不稳定时期，延迟可能会大大增加。