Raft协议理解

raft协议最关键的部分是领导选举和日志复制

日志复制

日志匹配原则：如果两个日志在相同索引位置的entry的任期号相同，那么这两个日志从头到这个索引位置之前完全相同。

日志匹配原则可以解释为如下两条

1. 如果在不同的日志中的两个条目拥有相同的索引和任期号，那么他们存储了相同的指令。

这基于一个事实，领导者在一个任期中，在一个索引位置最多只会有一条entry

1. 如果在不同的日志中的两个条目拥有相同的索引和任期号，那么他们之前的所有日志条目也全部相同。

有复制日志RPC中一致性检查保证，AppendEntriesRpc 参数携带了prevLogTerm和prevLogIndex，follower收到请求时，如果在自己的日志中找不到相同索引位置和任期号的entry就拒绝接收。

日志复制过程

1. 领导者维护了nextIndex[]，记录要发给每个follower的索引位置；领导者刚起来时，nextIndex赋值为最后一条entry的index + 1；
2. follower收到AppendEntry请求时检查发现prevLogIndex和prevLogTerm与自己不一致，会拒绝；leader收到拒绝响应后，会减小nextIndex，并重新发送AppendEntry；
3. 重复上面两步，最终会找到follower与leader entry匹配的位置，并从这个地方leader将数据复制给follower，最终达到follower与leader日志一致。

领导选举

简单说，领导选举会日志完整性最高的节点作为新的leader

怎么理解日志完整性？

论文“安全性->选举约束”里，明确规定了，新选出的leader必须包含之前所有已提交的日志，看如下两个场景：

有6个节点a ~ f

1. 开始6个节点日志都是一致的，且都commit了
2. leader a收到新的写，记logX, 并复制logX到其中两个follower b , c
3. leader挂掉，开始新的一轮领导选举，会出现两种情形：b/c当选 or d/e/f当选，都可以

有5个节点a ~ e

同样上述场景，只会有b/c当选，d/e无法当选

如果d 尝试参选，发送自己的lastLogIndex和lastLogTerm，因为b/c的lastLogIndex都比d的大，所以不会投票给d

由这两个场景对比可知，日志完整性高，讲究的是拥有前面所有已提交的entry，并不一定要有最新的entry，最新的entry可能是新写的，只有少部分节点有