根据 RAFT 论文，它提到除了领导服务器之外，每个服务器都有自己的日志条目和状态机，每个状态机处理来自日志的相同命令序列。
我对这种情况很少有疑问。
[1] 如果 1 个客户端向领导服务器发出一些请求，这是否意味着所有跟随服务器都处理请求并产生输出？但是谁将输出与客户端进行通信？
[2] 如果第一个问题的答案只是领导者将输出传回给客户端，那么多个追随者在其状态机中从日志条目计算/处理相同输入的用途是什么。因为已知 RAFT 确保所有日志条目必须包含相同顺序的相同命令。仅领导者在其状态机中处理来自日志的条目并将其返回给客户端就足够了吗？
[3] 另外，如果有多个客户端向服务器发出相同的请求，是只有领导者将输出传达给所有客户端还是跟随者出现在这里？
【问题讨论】：
标签： distributed consensus raft
你第一个问题的答案确实是leader的状态机输出返回给客户端。
从技术上讲，使用基本 Raft 协议，追随者没有理由必须立即将条目应用到他们的状态机。事实上，追随者通常甚至在领导者已经响应客户之后才知道条目的承诺。追随者将命令应用于其状态机的主要原因只是为了跟上领导者的步伐。如果领导者崩溃，追随者将被选为领导者，并需要接管服务客户端请求。一旦选择，新的领导者将在开始维修客户端请求之前将所有未申请的命令应用于其状态机。在追随者提交时对其应用命令可降低领导者更改的成本，而对追随者应用命令的成本无论如何也很低，因为它们不服务于客户端请求。
对追随者应用命令还有另一个原因，您的第三个问题接近于揭示它。只有领导者会响应客户端写入请求，但跟随者可以以宽松的一致性保证（顺序一致性）响应读取请求。为了做到这一点，领导者将完成命令的写入索引与输出一起返回。然后客户端可以查询一个追随者，一旦追随者的状态机至少达到了客户端最后一次写入的索引（由客户端提供），追随者可以查询状态机并返回输出。这允许客户端在领导者和追随者之间传播查询，这可能是实际系统确保追随者的状态机尝试跟上领导者状态的最佳原因。
【讨论】：