上图中， 最上面表示的index, S1～S5分别表示的是服务器， (a)~(b) 代表了不同的场景， 每个小块中的数字表示了itemid。
现分析如下：
(a) 场景: S1是leader，termId是2，写了一条日志到S1和S2，当前机群表示的leader表示为(termId：2，logIndex：2)。
(b) 场景：S1 挂， S5被选为leader(获得S3和S4的投票), 并在处于(termid:3, index:2)的位置上接受到了新的entry
(c) 场景：S5 挂，S1被选为leader, 并且termid:4, s1将index为2,term为2的entry复制到了s3上，此时已经满足过半数了， 那么此时S1能不能提交index：2上的entry呢？？
这里有两种情况：
1 ) 假如s1提交的话，则(index:2，term:2)的entry就被应用到状态机中了，是不可改变了，此时s1如果挂了，来到term5，s5是可以被选为leader的，因为按照之前的log比对策略来说，s5的最后一个log的term是3比s2 s3 s4的最后一个log的term都大。一旦s5被选举为leader，即d场景，s5会复制(index:2,term:3)的entry到上述机器上，这时候就会造成之前s1已经提交的index为2的位置被重新覆盖，因此违背了一致性。
- 假如s1不提交，而是等到term4中有过半的entry了，然后再将之前的term的entry一起提交（这就是所谓的间接提交，即使满足过半，但是必须要等到当前term中有过半的entry才能跟着一起提交），即处于e场景，s1此时挂的话，s5就不能被选为leader了，因为s2 s3的最后一个log的term为4比s5的3大，所以s5获取不到投票，进而s5就不可能去覆盖上述的提交。
日志覆盖的2种情况：
commitIndex之后的log覆盖:是允许的，如leader发送AppendEntries RPC请求给follower，follower都会进行覆盖纠正，以保持和leader一致。
commitIndex及其之前的log覆盖：是禁止的，因为这些已经被应用到状态机中了，一旦再覆盖就出现了不一致性。而上述案例中的覆盖就是指这种情况的覆盖。
从这个案例中我们得到的一个新约束就是：
Note :
当前term的leader不能“直接”提交之前term的entries
必须要等到当前term有entry过半了，才顺便一起将之前term的entries进行提交
所以raft靠着这2个约束来进一步保证一致性问题。
再来仔细分析这个案例，其问题就是出在：上述leader选举上，s1如果在c场景下将index为2、term为2的entry提交了，此时s5也就不包含所有的commitLog了，但是s5按照log最新的比较方法还是能当选leader，那就是说log最新的比较方法并不能保证3.1中的选举约束即
被选举出来的leader必须要包含所有已经比提交的entries
所以可以理解为：正是由于上述选举约束实现上的缺陷才导致又加了这么一个不能直接提交之前term的entries的约束。
也就是 leader 刚通过选举成为 leader 的时候，这时候的 commit index 并不能够保证是当前整个系统最新的 commit index，所以 Raft 要求当 leader 选举成功之后，首先提交一个 no-op 的 entry，保证 leader 的 commit index 成为最新的。
