RAFT算法运行中发生Leader变更时的客户端请求处理规则问询

结论 #

该场景下客户端不会判定为操作成功，应当返回 Leader Change 提示，或者返回请求超时类错误，由客户端发起重试。

具体逻辑说明 #

• Raft 协议明确要求：只有当一条操作日志被复制到超过半数的集群节点后，才会被 Leader 标记为已提交，只有已提交的日志才会被状态机执行、最终给客户端返回操作成功。你描述的场景中，原 Leader n1 仅将请求写入了自身本地日志，还未完成多数派复制就触发了选举，这条日志不满足提交条件，永远不会被执行。
• 新 Leader n2 选举成功后，会主动同步自己的日志到所有 Follower 节点，覆盖 Follower 本地和 Leader 不一致的未提交日志。n1 降级为 Follower 后，本地存储的那条未提交的操作日志会被直接覆盖丢弃，对应的操作相当于从未发生过。
• 原 Leader n1 感知到集群中有任期更高的新 Leader 后，会自动降级为 Follower，不会再给客户端返回操作成功的响应：如果客户端和 n1 还保持连接，会直接收到 n1 返回的非 Leader 错误；如果连接已经中断，客户端会触发请求超时，两种情况都会触发客户端的重试逻辑。

客户端常规处理规范 #

Raft 协议的标准客户端实现都会默认处理 Leader 变更场景：收到非 Leader 错误或者请求超时后，自动向集群其他节点查询最新的 Leader，将原请求重发给新 Leader 即可。为了避免重试导致的操作重复执行，客户端通常会给每个请求绑定唯一的序列号，Leader 节点会对已处理过的序列号请求直接去重，保证操作幂等。

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