我已经阅读了raft算法的论文，并得到了一个与raft在收到客户请求时执行的操作序列相关的问题：
为了克服单一故障点的情况，raft依赖于在其他机器上维护一个复制的日志，该算法还参考了一个共识模块来完成日志管理。操作顺序如下：
在leader的状态机上接收到客户端请求，leader将命令附加到其日志中。
leader向其追随者发送appendentries rpc，以在其本地日志中克隆该命令，并等待大多数追随者确认该条目已成功附加到其本地日志文件中。
一旦接收到确认请求已成功登录到大多数关注者日志中，则请求将提交到领导者的状态机，导致发生转换，并将该转换的输出返回给客户端。
最终，leader会通知后续AppendEntries rpc中提交的条目。
如果上述理解是正确的，那么我可以声明客户端请求被保留了一段时间，以便复制过程完成此外，我还可以声明客户机请求的成功在很大程度上取决于复制过程的成功（因为在收到大多数确认之前，客户机命令/请求不会在领导计算机上执行）。问题是，复制过程完成后，客户机请求平均需要多长时间才能收到响应，这对实时系统是否也有效？
最佳答案
http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed表明，请求CAP定理三位一体的一致性和可用性部分的Raft等系统将受到性能限制您可能还对https://pdfs.semanticscholar.org/7c45/54d064128043897ea2226021f6fda4c64251.pdf（birman对可靠多播经验的回顾）感兴趣，它描述了在高保证系统（如空中交通管制）中使用可靠多播组的经验。
我从中得到的收获是，一个真正的系统可能需要非常小心地处理它用Raft、Paxos和friends保护的信息，以及它可以不那么严密地保护的信息另一种观点是使用非常复杂的paxos实现，比如google扳手，这样程序员就不必担心非acid系统的问题。
关于algorithm - 筏算法正常操作，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/35708157/