Raft日志不一致处理：Follower如何协调冲突日志条目？

1. 该冲突日志场景是否可能出现？ #

是可能的，核心原因是旧任期未提交日志残留结合网络分区或Leader频繁切换：

• 举例：集群曾有任期2的Leader，生成日志条目2: X并仅同步给该Follower，但未复制到多数节点就崩溃，导致2: X从未被提交。
• 后续新Leader在任期3当选（其日志无2: X），生成2: B并同步到多数节点（包括当前Leader），接着生成3: C完成复制。
• 该Follower在任期2已写入2: X，之后因网络分区与集群断连，未同步任期3的2: B；分区恢复后，可能因临时网络波动导致部分日志先同步，最终形成1: A, 2: X, 3: C的冲突日志。

2. Follower如何与Leader日志达成一致？ #

Raft通过AppendEntries请求的校验与回溯机制解决该问题：
当Leader复制4: D时，会发送携带prevLogIndex=3、prevLogTerm=3（假设3: C由任期3的Leader创建）的AppendEntries请求：

• 若Follower的3: C任期为2（与Leader的3不匹配），会拒绝请求。
• Leader收到拒绝后，将prevLogIndex减至2，重新发送携带prevLogIndex=2、prevLogTerm=3的请求；Follower检查索引2处的2: X任期为2，不匹配，再次拒绝。
• Leader继续将prevLogIndex减至1，携带prevLogTerm=1（假设1: A来自任期1）；Follower索引1处日志任期匹配，接受请求。此时Leader会批量发送索引2及之后的所有日志（2: B、3: C、4: D）。
• Follower删除自身索引2及之后的冲突日志（2: X、3: C），追加Leader发送的条目，最终与Leader日志完全一致。

3. Raft如何高效处理日志不一致，无需逐个校验？ #

Raft通过两个核心设计避免低效的全量比对：

1. 日志一致性定理：Raft的选举规则确保合法Leader拥有集群中最完整的日志（最后一条日志任期最大，或任期相同但日志更长）。同时，Raft保证：若两个日志条目在相同索引位置有相同任期号，则它们之前的所有日志条目完全一致。这意味着，只要找到第一个匹配的prevLogIndex和prevLogTerm，该索引之前的日志无需再校验。
2. 智能回溯优化：Leader收到Follower的拒绝后，不会每次仅递减1个索引，而是可根据Follower返回的自身最后日志索引，快速跳转到可能匹配的位置，减少重试次数。一旦找到匹配点，Leader会批量发送后续所有日志条目，无需逐个传输。

内容的提问来源于stack exchange，提问作者JUAN DIEGO DIAZ ACEVEDO