筏算法正常运营

Question

我已阅读筏算法纸的，并得到了相关的操作顺序筏执行在接收到客户端请求一个问题：

为了克服故障情况的一个单点，筏依赖在其他机器上维护一个复制的日志，该算法还会为完整的日志记录管理咨询一个一致的模块。操作顺序如下：

1. 客户端请求在领导的状态机收到，领导追加命令到其日志。
2. 领导发送AppendEntries RPC给他的追随者在其本地日志中克隆该命令，并等待大多数追随者的确认，该条目已成功附加到其本地日志文件中。
3. 一旦确认已收到该请求已成功登录大多数追随者日志，那么请求被提交到领导者的状态机引起的转变发生，这种转变的输出返回返回给客户端。
4. 最终，领导者通知在后续AppendEntries的RPC致力于条目的追随者。

如果上面的理解是正确的，那么我就可以要求客户端的请求被关押了一点时间在复制过程来完成的，我也还可以要求一个客户端请求的成功在很大程度上依赖关于复制过程的成功（因为在领导者的机器上不执行客户端命令/请求，直到收到大多数确认）。问题是，在复制过程完成后，客户端请求接收响应的平均时间预计会达到多长时间，这对于实时系统是否也能有效地工作？

Answer 1

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed表明，系统，如筏请求CAP定理的三位一体的一致性和可用性部分会受到性能限制。您也可能对https://pdfs.semanticscholar.org/7c45/54d064128043897ea2226021f6fda4c64251.pdf（Birman提供的可靠多播体验的回顾）感兴趣，它描述了在高保证系统（如空中交通管制）中可靠的多播组的经验。

我从这个外卖是一个真正的系统可能要非常小心它与筏，Paxos的，和朋友守卫什么样的信息，以及它可以防守不太紧密。另一个观点是要实现Paxos的非常复杂的实现，例如Google Spanner，这样程序员就不必担心非ACID系统的问题。