Raft集群Follower是否存储Leader ID？请求重定向机制咨询

我查阅Raft论文中的持久化状态表格后，未发现Follower以标识符、物理地址等形式存储Leader信息的位置，仅在AppendEntries RPC中存在Leader ID字段，但该字段似乎并未被持久化保存。

想请教两个问题：

1. 若如表格所示，Follower未保存当前Leader的相关信息，它如何将发送至自身的请求重定向至Leader？
2. 若Follower实际保存了Leader信息，该信息在Follower侧是如何存储的？属于标识符类信息还是实际物理地址？

问题1解答 #

Raft协议里，Follower确实不需要持久化存储Leader信息，但这不代表它不会在内存中临时保存。当Follower接收到来自Leader的AppendEntries RPC时，会把RPC里的Leader ID和对应的物理地址（比如IP+端口）暂存在内存中。

如果有客户端请求打到Follower上，Follower直接用内存里缓存的Leader地址做重定向。要是Follower内存里没有缓存的Leader信息（比如刚启动、或者和Leader失联太久），它会直接返回"未知Leader"的响应，让客户端自己去尝试其他节点——或者有些实现里，Follower会发起一轮RequestVote RPC来重新确定Leader，但这不是协议强制要求的，属于具体实现的优化。

另外要注意：Raft协议的核心是保证一致性，重定向属于客户端交互层面的细节，协议本身只定义了集群内部的交互规则，客户端重定向的逻辑是由具体实现来补充的。

问题2解答 #

Follower实际会在内存中临时存储Leader的相关信息，不会持久化到磁盘。存储的内容通常包含两部分：

• Leader ID：这是集群内唯一的标识符（比如节点的UUID或者自定义编号），属于协议层面的必填信息，用来区分不同节点；
• 物理地址：比如节点的IP地址+端口号，这是用来实际发送RPC请求的网络地址，属于实现层面的信息，协议本身不做强制规定。

之所以不持久化，是因为Leader可能随时变化（比如Leader宕机后重新选举），持久化的信息很快就会过期，反而会导致错误的重定向。内存存储的临时信息刚好适配Leader的动态变化特性——一旦Follower长时间没收到Leader的心跳，就会清空缓存的Leader信息，进入候选者状态参与选举。

内容的提问来源于stack exchange，提问作者PkDrew