RAFT中的COMMITweixin44969471的博客-

先上结论：
Commit这个概念不仅仅需要考虑被大多数节点说接受，同时也需要考虑是否在当前任期，Leader只能Commit当前任期内的内容。

1. commit意味着什么

看下原文中的两处介绍。
An entry is considered committed if it is safe for that entry to be applied to state machines.
当日志安全被应用在状态机中时，则其为Commited。

The leader decides when it is safe to apply a log entry to the state machines; such an entry is called committed.
Leader决定将log应用到状态机的时间，应用的log则为Commited.

2. 需要明确的概念

Commit是如何进行维护的呢？

1. 首先是Leader确定大多数节点已经将日志复制到本地，随后Leader更新LeadCommit参数。

2. 接着各Server接受到新的心跳，收到Leader的信息，更新本地CommitIndex。

3. 投票选举的过程
   · 每一个Server会维持一个LastLogIndex和LastLogTerm，作为与其他节点交流时，进行新旧比较的依据。
   · 当Candidate发送给Follower RequestVote RPC请求后，Follower只会比较两个参数，LastLogIndex和LastLogTerm。只要这两个数据大于本地的数据，那Follower就会给对方投票。

3. 问题来了！

接下来我们要分析这里出现的情况，在已有的算法基础上，会不会有问题呢？

1. 在a阶段，S1作为Leader本地扩充了Log，并通过AppendEntries将信息发送给其他Server，其中S2收到信息并在本地执行相应日志。

2. 在b阶段，S1掉线，S5成为了Leader，这里接受到（S3，S4，S5）三者的投票。S5在任期3，扩充了Log后掉线。

3. 在c阶段，S1重新进入集群，并被选为Leader，S3接受到LeaderS1的信息，在本地扩充了任期2的日志。

4. 在d阶段，S5重新被选为Leader，这里为什么S5会被选了Leader呢？这是因为在进行投票时，Follower只会比较LastLogIndex和LastLogTerm，对于S5，这两个参数分别为2和3，而其他S2和S3的参数为2和2。这样的话，S5就可能会接收S2，S3，S4，S5四个人的投票。（具体需要参考投票过程部分）

而一旦S5成为了Leader，现在所有其他节点就会以S5任期3的Log为准。之前已经被大多数节点执行的Log就会被覆盖。这就会导致不一致性，前面已经被大多数节点接收的内容，不应该被覆盖。因为其已应用到状态机中，甚至可以理解为已经向外宣布取得共识，自然不应该被覆盖。

5. 图中还有一个e阶段，S1作为Leader将任期4的大多数日志复制给别的节点，这个时候S5就不会被选为新的Leader，也就不会出现之后的覆盖问题。
   （这里可以理解为同时Commit2条日志。）

4. 思考

为何Raft算法在进行投票时，不对CommitIndex进行比较呢？
个人觉得这应该是一种解决方案。

而Raft是让leader不允许commit之前任期里的任何日志，也就是说虽然term2的日志已经被大多数节点复制，leader不会设置LeaderCommit为2，而是等待自己在任期4的日志被大多数节点接受后，设置LeaderCommit为3，这样index为2的log也一并Commit了。

5. 总结

Commit这个概念不仅仅需要考虑被大多数节点所接受，同时也需要考虑是否在当前任期，Leader只能Commit当前任期内的内容。

参数算法：