Leadre针对每个Follower维护了一个nextIndex，表示下一个要发送给Follower的日志条目的索引。当一个Leader刚被选举出时，将nextIndex初始化为自己最新日志的index+1。如果AppendEntries 请求被拒绝，Leader会减小nextIndex进行重试，直到在某个位置Leader和Follower的日志一致，则AppendEntries RPC成功，Follower上冲突的日志条目会全部删除并加上Leader的日志。这时，Follower的日志就会和Leader保持一致。
之前任期日志条目的处理
本轮任期的Leader不能提交一个之前任期内的日志条目，否则可能会出现下述情况
在阶段a，term为2，S1是Leader，且S1写入日志（term, index）为(2, 2)，并且日志被同步写入了S2；
在阶段b，S1离线，触发一次新的选主，此时S5被选为新的Leader，此时系统term为3，且写入了日志（term, index）为（3， 2）;
S5尚未将日志推送到Followers变离线了，进而触发了一次新的选主，而之前离线的S1经过重新上线后被选中变成Leader，此时系统term为4，此时S1会将自己的日志同步到Followers，按照上图就是将日志（2， 2）同步到了S3，而此时由于该日志已经被同步到了多数节点（S1, S2, S3），因此，此时日志（2，2）可以被commit了（即更新到状态机）；
在阶段d，S1又很不幸地下线了，系统触发一次选主，而S5有可能被选为新的Leader（这是因为S5可以满足作为主的一切条件：1. term = 5 > 4，2. 最新的日志为（3，2），比大多数节点（如S2/S3/S4的日志都新），然后S5会将自己的日志更新到Followers，于是S2、S3中已经被提交的日志（2，2）被截断了，这是致命性的错误，因为一致性协议中不允许出现已经应用到状态机中的日志被截断。
为了避免这种错误，Raft要求只有Leader当前term里的日志可以被提交。当然，由于日志匹配特性，之前的日志条目也会被提交。
参考链接：https://zhuanlan.zhihu.com/p/27207160