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感兴趣(Birman对可靠多播经验的回顾)，它描述了高保证系统(如空中交通控制)中的可靠组播组的经验。

我从中得到的启示是，一个真正的系统可能需要非常小心地使用筏子、帕克斯和朋友来保护哪些信息，以及哪些信息可以不那么严密地保护。另一种观点是采用非常复杂的Paxos实现，比如Google，这样程序员就不必担心非酸性系统的问题了。

Answer 2

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

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

我还可以声称，客户端请求的成功在很大程度上取决于复制过程的成功。

这也是正确的。集群中至少大多数节点(包括领导者)都需要可用和响应，这样才能成功地复制命令，并使领导者能够确认请求。

在复制过程完成后，客户端请求接收响应所需的平均时间是多少？

这取决于网络的拓扑结构。对客户端请求的响应的延迟将由以下部分组成(假设没有领导者崩溃)：*客户机请求在客户机和领导者之间传输所需的延迟。*领导者向追随者发出的AppendEntries请求复制条目的延迟(与所有追随者并行发送)。*追随者对领导者的AppendEntries反应的潜伏期。*领导者将命令应用到其状态机所需的时间(即在最佳情况下为磁盘写入)*从领导者发送到客户端的客户机响应的延迟时间。

各种消息的延迟取决于节点之间的距离，但可能是十分之一到数百毫秒。

这对实时系统也有效吗？

这取决于你对具体情况的要求。但是一般来说，实时系统需要几毫秒以下的延迟，所以答案很可能是否定的。此外，请记住，在发生新领导人选举的崩溃和不稳定时期，延迟会显著增加。