Raft算法正常操作
Raft Algorithm Normal Operations
我已经阅读了 Raft 算法论文，并且有一个与 Raft 在收到客户端请求时执行的操作顺序相关的问题：
为了克服单点故障的情况，Raft 依赖于在其他机器上维护一个复制的日志，该算法还参考了一个共识模块来完成日志管理。操作顺序如下：
- 领导者的状态机接收到客户端请求，领导者将命令附加到其日志中。
- 领导者向他的追随者发送 AppendEntries RPC 以将命令克隆到他们的本地日志中，并等待大多数追随者确认条目已成功附加到他们的本地日志文件。
- 一旦收到请求已成功记录在大多数追随者日志中的确认，则请求将提交给领导者的状态机，从而导致发生转换，并将该转换的输出返回给客户。
- 最终，领导者会在后续 AppendEntries RPC 中通知追随者已提交的条目。
如果上面的理解是正确的，那么我可以说客户端请求被保留了一段时间以完成复制过程，我也可以说客户端请求的成功在很大程度上取决于复制过程的成功（因为在收到多数确认之前，客户端命令/请求不会在领导者的机器上执行）。问题是，在复制过程完成后，客户端请求平均需要多长时间才能收到响应，这对实时系统是否有效？
http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed suggests that systems such as Raft requesting the Consistency and Availability parts of the CAP theorem's trinity will suffer performance limits. You may also be interested in https://pdfs.semanticscholar.org/7c45/54d064128043897ea2226021f6fda4c64251.pdf（A review of experiences with reliable multicast, by Birman），描述了空中交通管制等高保障系统中可靠组播组的经验。
我从中得出的结论是，一个真实的系统可能需要非常小心地了解它用 Raft、Paxos 和朋友保护的信息，以及它可以不那么严格地保护的信息。另一种观点是去寻求一个非常成熟的Paxos实现，比如GoogleSpanner，这样程序员就不用担心非ACID系统的问题了。
If above understanding is correct, then I can claim that the client request is being held for a bit of time for the replication process to complete
正确，当前任期的领导者只有在命令被复制到集群中的大多数节点后才会确认客户端请求。
I may also claim that the success of a client request is heavily dependent on the success of the replication process
也对。至少集群中的大多数节点（包括领导者）需要可用和响应，以便成功复制命令和领导者确认请求。
how long it is expected to take on average for a client request to receive a response after the replication procedure is completed
这取决于您的网络拓扑。响应客户端请求的延迟将由以下部分组成（假设没有领导者崩溃）：
* 客户端请求在客户端和领导者之间传输所需的延迟。
* AppendEntries 从领导者到追随者复制条目的请求的延迟（并行发送给所有追随者。
* 跟随者对领导者的 AppendEntries 响应的延迟。
* 领导者将命令应用到其状态机所需的时间（即最好情况下的磁盘写入）
* 客户端响应从领导者传输到客户端的延迟
各种消息的延迟取决于节点之间的距离，但可能在十分之一到数百毫秒的数量级。
also does that work efficiently for real-time systems?
这取决于您对具体情况的要求。但总的来说，实时系统要求延迟低于几毫秒，所以答案很可能是否定的。此外，请记住，在发生新领导人选举的崩溃和不稳定期间，延迟可能会显着增加。
我已经阅读了 Raft 算法论文，并且有一个与 Raft 在收到客户端请求时执行的操作顺序相关的问题：
为了克服单点故障的情况，Raft 依赖于在其他机器上维护一个复制的日志，该算法还参考了一个共识模块来完成日志管理。操作顺序如下：
- 领导者的状态机接收到客户端请求，领导者将命令附加到其日志中。
- 领导者向他的追随者发送 AppendEntries RPC 以将命令克隆到他们的本地日志中，并等待大多数追随者确认条目已成功附加到他们的本地日志文件。
- 一旦收到请求已成功记录在大多数追随者日志中的确认，则请求将提交给领导者的状态机，从而导致发生转换，并将该转换的输出返回给客户。
- 最终，领导者会在后续 AppendEntries RPC 中通知追随者已提交的条目。
如果上面的理解是正确的，那么我可以说客户端请求被保留了一段时间以完成复制过程，我也可以说客户端请求的成功在很大程度上取决于复制过程的成功（因为在收到多数确认之前，客户端命令/请求不会在领导者的机器上执行）。问题是，在复制过程完成后，客户端请求平均需要多长时间才能收到响应，这对实时系统是否有效？
http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed suggests that systems such as Raft requesting the Consistency and Availability parts of the CAP theorem's trinity will suffer performance limits. You may also be interested in https://pdfs.semanticscholar.org/7c45/54d064128043897ea2226021f6fda4c64251.pdf（A review of experiences with reliable multicast, by Birman），描述了空中交通管制等高保障系统中可靠组播组的经验。
我从中得出的结论是，一个真实的系统可能需要非常小心地了解它用 Raft、Paxos 和朋友保护的信息，以及它可以不那么严格地保护的信息。另一种观点是去寻求一个非常成熟的Paxos实现，比如GoogleSpanner，这样程序员就不用担心非ACID系统的问题了。
If above understanding is correct, then I can claim that the client request is being held for a bit of time for the replication process to complete
正确，当前任期的领导者只有在命令被复制到集群中的大多数节点后才会确认客户端请求。
I may also claim that the success of a client request is heavily dependent on the success of the replication process
也对。至少集群中的大多数节点（包括领导者）需要可用和响应，以便成功复制命令和领导者确认请求。
how long it is expected to take on average for a client request to receive a response after the replication procedure is completed
这取决于您的网络拓扑。响应客户端请求的延迟将由以下部分组成（假设没有领导者崩溃）：
* 客户端请求在客户端和领导者之间传输所需的延迟。
* AppendEntries 从领导者到追随者复制条目的请求的延迟（并行发送给所有追随者。
* 跟随者对领导者的 AppendEntries 响应的延迟。
* 领导者将命令应用到其状态机所需的时间（即最好情况下的磁盘写入）
* 客户端响应从领导者传输到客户端的延迟
各种消息的延迟取决于节点之间的距离，但可能在十分之一到数百毫秒的数量级。
also does that work efficiently for real-time systems?
这取决于您对具体情况的要求。但总的来说，实时系统要求延迟低于几毫秒，所以答案很可能是否定的。此外，请记住，在发生新领导人选举的崩溃和不稳定期间，延迟可能会显着增加。