1

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

为了克服单点故障场景，Raft 依赖于在其他机器上维护一个复制的日志，该算法还参考了一个共识模块来进行完整的日志管理。操作顺序如下：

  1. 领导者的状态机接收到客户端请求，领导者将命令附加到其日志中。
  2. 领导者向他的追随者发送AppendEntries RPC 以在他们的本地日志中克隆命令，并等待大多数追随者确认该条目已成功附加到他们的本地日志文件中。
  3. 一旦接收到请求已成功记录在大多数追随者日志中的确认，然后该请求将提交到领导者的状态机，从而发生转换，将该转换的输出返回给客户端。
  4. 最终，领导者在后续的AppendEntries RPC中通知追随者提交的条目。

如果上述理解是正确的，那么我可以声称客户端请求被保留一段时间以完成复制过程，我也可以声称客户端请求的成功很大程度上取决于复制的成功进程（因为在收到多数确认之前，不会在领导者的机器上执行客户端命令/请求）。问题是，在复制过程完成后，客户端请求平均需要多长时间才能收到响应，这对于实时系统也有效吗？

4

2 回答 2

2

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

我从中得出的结论是，一个真实的系统可能希望非常小心它用 Raft、Paxos 和朋友保护哪些信息，以及它可以不那么严格地保护哪些信息。另一种观点是去Paxos的一个非常复杂的实现，比如Google Spanner，这样程序员就不用担心非ACID系统的问题了。

于 2016-03-01T06:34:15.067 回答
0

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

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

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

这也是正确的。至少集群中的大多数节点（包括领导者）需要可用和响应，以便成功复制命令并且领导者确认请求。

复制过程完成后，客户端请求平均需要多长时间才能收到响应

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

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

这对实时系统也有效吗？

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

于 2019-09-13T14:07:48.453 回答