TIPS Raft Committing entries from previous terms

本文是我对与Raft论文3.6.2节的理解。写这篇文章的原因是因为理解这段内容确实花了一些功夫。

面向对象：懂得Raft，同时也对3.6.2节有疑问，并且看了“参考”这里面几个之后还不是很清晰的同学。

NOTE: 3.6.2节是《CONSENSUS: BRIDGING THEORY AND PRACTICE》这篇论文的，对应《In Search of an Understandable Consensus Algorithm(Extended Version)》是5.4.2节。

看这篇文章之前先看一下Raft 5.4.2 Committing entries from previous terms的理解，如果看的懂得话，就不用再看这个了，否则再看看我的理解，是否能有帮助。

3.6.2这一节的正文和描述的问题就不再说一遍了，贴个图帮助查看吧。

首先，这个图中描述的D1和D2都是可能存在的，它们都是“合法”存在的场景。
其次，这节内容的目的是想说明，Leader不能直接“提交”之前term(previous terms)的日志，不能按照“大多数”应答的逻辑去提交之前term的日志。只有当前term的日志，复制后收到了大多数节点的应答，才可以提交这个日志。但是之前term的，是不能“提交”的。那么，之前term的日志怎么提交呢？文中的说法是，follower节点的数据要保持跟leader节点一致。那么当follower满足接受当前最新日志的条件，并且接受了最新的日志，它的旧日志也要保持跟leader一致。如果最新的日志提交了，那么最新的日志之前的日志也就提交了。
最后，这里还描述了一个现象，就是大多数节点都有的日志，也不一定就是“提交”状态的日志，只有当前leader term发起的，大多数节点都有的，才可能是“提交”状态的日志。这里说的就是“黄色”index=2的日志。

另外，我翻阅了braft的代码，发现并没有对这种场景做特殊处理，更加印证了我的理解。

总结一下，很简单，就是leader不会直接“提交”之前term的日志，只会通过复制，提交当前term的日志。之前term的日志，都是通过Raft协议中描述的，新日志提交了，旧日志也一定提交了，这个顺序要求。

这种机制会带来一个问题，导致raft复制变慢。就是假设由于网络原因，集群的term增长了，但是原来的leader后来又选为leader了，那么这个leader是不能提交之前term的日志，只能等新的term的日志一起提交。

参考

1. Raft 5.4.2 Committing entries from previous terms的理解

2. raft算法中，5.4.2节一疑问

3. Does this cause a real problem when I adopt the Raft’s “never commits log entries from previous terms by counting replicas” rule in this situation?

4. How does raft handle committing entries from previous one?