no-op日志
为什么 Leader 不能提交之前任期的日志，只能通过提交自己任期的日志，从而间接提交之前任期的日志。
先按错误的情况，也就是 Leader 可以提交之前任期的日志。那么上述的流程：
- s1 是任期 2 的 Leader(仔细看，有个黑框)，日志已经复制到了 s2。
- s1 宕机，s5 获得 s3、s4 和 s5 的选票成为 Leader，然后写了一条日志 index=2 & term=3。
- s5 刚写完就宕机了，s1 重新当选 Leader，currentTerm = 4，此刻还没有新的请求进来，s1 将 index=2 & term = 2 的日志复制到了 s3，多数派达成，s1 提交了这个日志(注意，term=2 不是当前任期的日志，我们在讨论错误的情况)。然后请求进来，刚写了本地 index=3 & term=4 的日志，s1 就故障了。
- 这时候 s5 可以通过来自 s2、s3、s4 和自己的投票，重新成为 Leader(currentTerm>=5)，并将 index=2 && term=3 的日志复制到其他所有节点并提交，此时 **index=2 的日志提交了两次！**一次 term=2，一次term=3，这是绝对不允许发生的，已经提交的日志不能够被覆盖！
- 这里的情况是，S1 在宕机之前将自己 term=4 的日志复制到了大多数机器上，这样 S5 就不可能选举成功。这是 S1 不发生故障，正确复制的情况。
这里主要通过 © 和 (d) 来说明问题所在。其实这张图用 Raft 大论文的图会比较好理解。(d) 和 (e) 分别对应 term=4 有没有复制到多数派的情况。
所以，我们要增加提交的约束，不让 (d) 这种情况发生。这个约束就是，Leader 只能提交自己任期的日志。
我们再来看看，加了约束后会变成什么样？前面 (a) 和 (b) 没有任何改变，我们从 © 开始。
- © 还是将 index=2 & term=2 复制到大多数，由于 currentTerm = 4，所以不能提交这条日志。如果 s1 将 term = 4 的日志复制到多数派，那么 Leader 就可以提交日志，index=2 & term=2 也会间接一起提交，其实这就是 (e) 的情况，1-2-4 都被提交。
- (d) 的情况我觉得是理解问题的关键。如果 S1 只将 term=4 写入自己的日志，然后宕机了；S5 选举成功成为 Leader，然后将 index=2 & term=3 的日志复制到所有节点，现在 index=2 是没有提交过的，S5 能提交 index=2 & term=3 的日志吗？
答案是不能。因为 S5 在 S1(term=4) 选举出来后 currentTerm 至少是 5，也可能是 6、7、8……我们假设就是 5，但这条日志 term = 3，**Leader 不能提交之前任期的日志，所以这条日志是不能提交的。**只有等到新的请求进来，超过半数节点复制了 1-3-5 后，term=3 的日志才能跟着 term=5 的一起提交。
虽然加了这个约束不会重复提交了，但如果一直没新的请求进来，index=2 & term=3 岂不是就一直不能提交？那这里不就阻塞了吗？如果这里是 kv 数据库，问题就很明显了。假设 © 或 (d) 中 index=2 那条日志里的 Command 是 Set("k", "1")，S5 当选 Leader 后，客户端来查询 Get("k")，Leader 查到日志有记录但又不能回复 1 给客户端(因为按照约束这条日志未提交)，线性一致性要求不能返回陈旧的数据，Leader 迫切地需要知道这条日志到底能不能提交。
所以 raft 论文提到了引入 no-op 日志来解决这个问题。这个在 etcd 中有实现。
引入 no-op 日志
no-op 日志即只有 index 和 term 信息，command 信息为空。也是要写到磁盘存储的。
具体流程是在 Leader 刚选举成功的时候，立即追加一条 no-op 日志，并立即复制到其它节点，no-op 日志一经提交，Leader 前面那些未提交的日志全部间接提交，问题就解决了。像上面的 kv 数据库，有了 no-op 日志之后，Leader 就能快速响应客户端查询了。
有了 no-op 日志之后，Leader 就能快速响应客户端查询了。
本质上，no-op 日志使 Leader 隐式地快速提交之前任期未提交的日志，确认当前 commitIndex，这样系统才会快速对外正常工作。