共计 1641 个字符，预计需要花费 5 分钟才能阅读完成。
后面咱们介绍了 Raft 算法，接下来会分篇讲述每一个局部，明天讲述选举的细节。
在讲述选举之前，先介绍下 Raft 算法根底。
一、Raft 根底
1、节点角色
在 Raft 中，在任意时刻，服务器节点只能是以下 3 个角色之一：
Follower（跟随者）：系统启动时默认的角色，一般来说不参加客户端读、写申请，承受 Leader 发送过去的心跳追加日志，在 Leader 挂了之后转变为 Candidate；
Candidate（候选人）：如果以后没有 Leader，Follower 就转变为这个角色，这个角色会向其它节点发动投票申请，如果少数节点批准投票，则晋升为 Leader；
Leader（领导人）：承受客户端的读、写申请，协调整个日志的长久化和推动；
上面讲节点角色时对立用英文形容。
2、节点角色状态迁徙图
系统启动时，大家都是 Follower，而后启动定时器，如果在指定工夫没有收到 Leader 的心跳，则将本人变成 Candidate，而后向其它成员发动投票申请，如果收到过半以上成员的投票则 Candidate 晋升为 Leader；
Leader 发送心跳给其它成员时如果收到的响应中 term 比本人的大，则进化成 Follower；
3、逻辑时钟 (term)
选举过程有个 term 参数，这个参数就是逻辑时钟，这是一个整数，全局递增；Raft 把工夫宰割成任意长度的任期，用 term 来标识每一届 leader 的任期，这样能够保障在一个任期内只有一个 Leader。
逻辑时钟规定如下：
Candidate 发动选举时就将本人的 term 加 1，而后发动投票申请；
收到投票申请的节点比拟申请的 term 和本人的 term，如果申请的 term 比本人的大，则更新本人的 term；
这样在即便每个节点的工夫不一样的状况下也能够推动逻辑时钟；
4、状态
下面的状态是所有节点都要保留的，并且要长久化的，即每次变更马上要写入磁盘。
下面的状态是保留在内在中，每次重启后都 0 开始，即不须要长久化到磁盘上。
上述只有在 Leader 节点才会须要保留，并且是也是保留在内存中，不须要长久化，重启后从 0 开始。
二、领导人选举
领导人选举产生的条件为 Follower 没收到 Leader 的心跳，具体场景个别如下：
1、系统启动时
2、Leader 挂了或网络分区了
具体细节如下：
1、申请投票 RPC
由候选人发动
返回值
接管申请投票的节点响应规定如下：
- 如果 term < currentTerm 返回 false；
- 如果 votedFor 为空或者为 candidateId，并且候选人的日志至多和本人一样新，那么就投票给他；
第 1 条规定好了解，第 2 条规定后面局部是为了保障在一个任期内每个节点只投 1 票，后面也说过这个信息是要长久化的；
候选人的日志至多和本人一样新：这里说的就比拟抽象了，这里的意思是要看下各自最初 1 条日志，即两者的索引号和 term 都对的上，咱们看一个理论的例子：
下面的例子从上往下假如别离为 A、B、C、D、E 节点，A 以后为 Leader，各节点日志索引如下：
A：8
B：5
C：8
D：2
E：7
如果这时候 A 挂了，如果 D 最先降级为 Candidate，B、C、E 收到申请后都不会为 D 投票，拿 B 来说，B 发现 D 的最初一条日志索引为 2，而本人的日志索引为 8，因而回绝 B 的申请。
对于选举还有其它一些规定：
1、针对 Follower
如果在超过选举超时工夫的状况之前都没有收到 Leader 的心跳，或者是 Candidate 申请投票的，就本人变成 Candidate;
2、针对 Candidate
开始选举后的动作如下：
自增以后的任期号（currentTerm）;
给本人投票;
重置选举超时计时器;
发送申请投票的 RPC 给其余所有服务器;
收到响应后的规定：
如果接管到大多数服务器的选票，那么就变成 Leader；
如果接管到来自新的领导人的心跳信息，则转变成 Leader；
如果选举过程超时，再次发动一轮选举;
3、针对 Leader
一旦成为领导人：发送空的附加日志 RPC（心跳）给其余所有的服务器；
在肯定的空余工夫之后不停的反复发送，以阻止跟随者超时。
