后面咱们介绍了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（心跳）给其余所有的服务器；
在肯定的空余工夫之后不停的反复发送，以阻止跟随者超时。