Raft共识算法Leader Election相关技术问题咨询

问题1：无Leader期间如何处理客户端请求？ #

• 集群内所有Follower节点直接拒绝客户端的写请求，返回明确提示（比如"当前集群无可用Leader，请稍后重试"），避免产生不一致的数据
• 客户端需实现指数退避重试策略，减少对集群的无效请求压力
• 对于读请求，若业务允许弱一致性，可让Follower返回本地已提交的日志数据，但必须向客户端明确说明该数据可能不是最新版本；如果强一致性要求严格，同样拒绝读请求，等待Leader选举完成

问题2：脑裂后高term故障节点恢复，如何与集群同步？ #

• 故障节点恢复连接后，会向集群节点发送RPC请求（RequestVote或AppendEntries），此时它的term（12）远高于集群当前term（2）
• 集群内的节点收到高term的RPC后，会立即更新自身term到12，切换为Follower状态，并在响应中携带自己的日志信息
• 故障节点收到响应后，发现自己的日志与多数节点不一致，会自动降级为Follower
• 集群会触发新的Leader选举（term=12），新Leader通过AppendEntries RPC向故障节点同步日志：
  • 对比双方日志的term和索引，定位故障节点缺失的日志条目
  • 逐步推送缺失的日志，直到故障节点的日志与集群完全一致
• 整个过程由Raft协议自动完成，核心依赖term的全局优先级和日志一致性校验机制

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