Raft 协议

Raft

领导者选举

Raft 使用一种心跳机制来触发领导者选举。当使用 Raft 协议的集群启动时，集群中的所有节点的角色都是 Follower，Follower 会维护一个选举计时器，如果选举计时器超时（计时时间内没有收到领导者的任何消息），那么 Follower 会认为 Leader 已经下线，他将转换角色为 Candidate，同时向集群中的所有节点发送请求投票的 RPC 请求，此时，进入选举阶段，选举阶段会产生三种结果：

1. 他自己赢得了这次选举：当一个候选人获得了大多数服务器节点针对同一任期号的选票，他就会成为 Leader
2. 其他服务器成为领导者：当其他服务器比他先成为 Leader ，他会收到这个 Leader 的心跳请求，这个心跳请求会携带一个任期号，如果请求的任期号不小于自己的任期号则自己会成为 Follower，如果自己的任期号大于这个Leader 的任期号，他会拒绝心跳，维持自己 候选人 的状态等待新的一轮投票
3. 一段时间后都没有人获胜：这个场景是有多个 Follower 同时成为 Candidate，导致选票被瓜分，为了防止选票被瓜分，Follower 在设置选举计时器的时间是从一个时间区间随机选择的（150ms - 300ms），这样可以把服务器都分散开，在大多数情况下只有一个选举计时器会超时

日志复制

一旦一个领导者被选举出来了，他就会开始为客户端提供服务，客户端的每个请求都包含一条被复制状态机执行的指令，领导者把这个指令作为一条新的日志条目附加到日志中去，然后并行的发送附加条目的 RPC 给其他服务器让他们复制这条日志，当这条日志被安全的复制，领导者会应用这条日志条目到他的状态机中，然后返回结果给客户端。

Raft 保证所有已经提交的日志条目都是持久化的并且最终会被所有可用的状态机执行，当一条日志被大多数节点复制了，这个日志就是可提交的。领导者跟踪了最大的将会被提交的日志项的索引，并且索引值会被包含在未来所有附加日志的 RPCs 中，这样其他服务器才会最终知道领导者的提交位置。

领导者会把新的日志条目紧接着之前的日志条目的索引和任期都发送给各个服务器，如果跟随者在他的日志中找不到包含相同索引位置和任期号的条目，那么他就会拒绝接受新的日志条目.

如果一个跟随者和领导者的日志不一致，那么在下次附加日志 RPC 的时候，一致性检查会失败，在被跟随者拒绝之后，领导者就会减小 nextIndex 值进行重试，最终 nextIndex 会在某个位置使得领导者和跟随者的日志达成一致，一旦 macthIndex 比 nextIndex 小 1 那么领导者开始发送实际的日志条目

安全性

安全性保证了任何领导者对于给定的任期号都拥有了之前任期的所有被提交的日志条目

选举限制

• Raft 使用投票的方式来阻止一个候选人赢得选举除非这个候选人包含了所有已提交的日志条目，如果一个候选人的日志条目和大多数的服务器节点一样新，那么他一定持有了所有已提交的日志条目
• 请求投票的 RPC 实现了这样的限制：RPC 中包含了候选人的日志信息。然后投票人会拒绝那些日志没有自己新的投票请求
• Raft 永远不会通过计算副本数目来提交一个之前任期内的日志条目，只有领导者当前任期内的日志条目通过计算副本数目可以被提交，一旦当前任期的日志条目以这种方式被提交，那么由于日志匹配特性，之前的日志条目也都会被提交