服务器如何在 RAFT 中与客户端通信?

How does the server communicate back to the client in RAFT?

根据 RAFT 论文,它提到除了领导服务器之外的每个服务器都有自己的日志条目和状态机,每个状态机处理来自日志的相同命令序列。

我对这种情况几乎没有疑问。

[1] 如果 1 个客户端向领导服务器发出一些请求,是否意味着所有跟随服务器都处理请求并产生输出?但是谁将输出与客户端通信?

[2] 如果第一个问题的答案只是领导者将输出传回给客户端,那么多个追随者的用途是什么 computing/processing 他们的状态机中来自日志条目的相同输入。因为它已经知道 RAFT 确保所有日志条目必须包含相同顺序的相同命令。仅领导者在其状态机中处理日志中的条目并将其返回给客户端就足够了吗?

[3] 此外,如果有多个客户端向服务器发出相同的请求,是只有领导者将输出传达给所有客户端,还是跟随者会出现在这里?

  1. 你第一个问题的答案确实是领导者的状态机输出return发送给客户端。

  2. 从技术上讲,使用基本的 Raft 协议,追随者 没有理由立即将条目应用到他们的状态机。事实上,在领导者已经对客户做出回应之前,追随者通常甚至不知道条目的承诺。跟随者向其状态机应用命令的主要原因只是为了跟上领导者的步伐。如果 leader 崩溃,follower 将被选为 leader 并需要接管服务客户端请求。 Once elected, the new leader will have to apply all unapplied commands to its state machine before it can begin servicing client requests.在追随者提交时对其应用命令可降低领导者变更的成本,并且在追随者上应用命令的成本无论如何都很低,因为它们不服务于客户端请求。

  3. 对追随者应用命令还有另一个原因,您的第三个问题接近揭露它。只有领导者会响应客户端 write 请求,但跟随者可以响应 read 具有宽松一致性保证(顺序一致性)的请求。为了做到这一点,leader returns 已完成命令的写入索引以及输出。客户端然后可以查询跟随者,一旦跟随者的状态机至少达到客户端最后一次写入的索引(由客户端提供),跟随者可以查询状态机和 return 输出。这允许客户端在领导者和追随者之间传播查询,这可能是实际系统确保追随者的状态机试图跟上领导者的状态的最佳原因。