algorithm - Raft算法正常操作

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 感兴趣(A review of experiences with reliable multicast, by Birman)，描述了空中交通管制等高保障系统中可靠组播组的经验。

我从中得出的结论是，一个真实的系统可能需要非常小心地了解它用 Raft、Paxos 和 friend 保护的信息，以及它可以不那么严格地保护的信息。另一种观点是寻求非常复杂的 Paxos 实现，例如 Google Spanner，这样程序员就不必担心非 ACID 系统的问题。