raft协议问题

简单介绍raft的基础知识

角色

Raft通过选举Leader并由Leader节点负责管理日志复制来实现多副本的一致性。

在Raft中，节点有三种角色：

• Leader：负责接收客户端的请求，将日志复制到其他节点并告知其他节点何时应用这些日志是安全的
• Candidate：用于选举Leader的一种角色
• Follower：负责响应来自Leader或者Candidate的请求

角色转换如下图所示：

 

• 所有节点初始状态都是Follower角色
• 超时时间内没有收到Leader的请求则转换为Candidate进行选举
• Candidate收到大多数节点的选票则转换为Leader；发现Leader或者收到更高任期的请求则转换为Follower
• Leader在收到更高任期的请求后转换为Follower

节点的状态时通过心跳包来进行维持的。

问题1：Leader选举，为什么要分配一段”随机的”超时时间？

产生的原因：

如果一个follower在election timeout的时间里没有收到leader的信息,就进入新的term,转成candidate,给自己投票,发起选举 RequestVote RPC. 这个状态持续到发生下面三个中的任意事件:

1. 它赢得选举
2. 另外有Server获得选举
3. 1个term过去了,还是没有选举结果

为什么会有3这个情况呢，前两个很好理解，说一下第三个产生的原因，当如果大家同时发起选举，都投给自己，那就没有节点能够得到多数选票了，这个时候就要进入下一个term，再选一次，如果每次的election time的时间相同就会陷入死循环。 为了避免这个情况持续发生，每个Server的election time被随机的设成不同的值，所以先timeout的就可以先发起下一次选举。

Raft 算法使用随机选举超时时间的方法来确保很少会发生选票瓜分的情况，就算发生也能很快的解决。因为超时时间相同的话，一旦两个Candidate选举发生选票瓜分情况而无法选出Leader,并且后续也很可能继续发生选票瓜分。影响Raft的正常运行。而随机时间是最简单也最容易理解的解决方式。

动画演示：http://thesecretlivesofdata.com/raft/#election

问题2：若Follower节点与Leader节点日志出现不一致怎么办？

选好leader之后就可以分发log啦.

每一个log都有一个log index 和 term number。当大多数的follower都复制好这个log时，就说这个log是committed，可以执行了。 Leader 记住已经commit的最大log index， 用它来分发下一个 RPC。 这个和TCP里段的编号的作用是一样的。

Leader通过Append Entries RPC请求失败发现Follower节点与自己日志不一致，领导人针对每一个跟随者维护了一个 nextIndex，这表示下一个需要发送给跟随者的日志条目的索引地址。当一个领导人刚获得权力的时候，他初始化所有的 nextIndex 值为自己的最后一条日志的index加1。当Append Entries RPC失败时，领导人会不断减小 nextIndex 值并进行重试。最终 nextIndex 会在某个位置使得领导人和跟随者的日志达成一致。这时就会把跟随者冲突的日志条目全部删除并且加上领导人的日志。