Raft算法简介

Stanford的新的分布式协议raft算法作为paxos算法的替代品（Paxos难于理解，难以实现），优点是更注重协议的可理解性以及可落地性，已经在etcd，consul中应用。该协议各节点之间如同主从模式,由一个节点负责接收命令,然后通知各个从节点,当过半数节点确认后,则该命令生效.

raft协议中节点分为三种状态：

1.Follower：所有结点都以follower的状态开始，负责跟随leader保持同步状态，选主时负责投票。如果leaderheartbeat timeout ②会进入candidate状态。

2.Candidate ：由超时的follower转变而来，会发起新一轮的选主投票过程，会投自己一票并且发起RequestVote RPC给其余节点，要求投票，得到超过半数的candidate将成为新的leader。

3.Leader：一般一个任期（term ①）内只有一个leader，主要负责处理所有客户端交互，发送heartbeat消息（Append Entries messages）维护更新其余follower日志状态。

                                            ps:任一状态下发现高于当前任期的新任期的合法leader时候会变成该Leader的Follower

raft协议总共有两种过程,分别是election(用于选主)以及log replication(用于保持各节点一致):

election过程：

当follower的heartbeat超时，则自增currentTerm，由Follower转换为Candidate，设置votedFor为自身（投自己一票），并行发起RequestVote RPC，等待其他节点投票，不断重试，直至满足以下任一条件：

1. 获得超过半数Server的投票，转换为Leader，广播Heartbeat

2. 接收到合法Leader的AppendEntries RPC，转换为Follower

3. 选举超时(election timeout ③)，没有Server选举成功，自增currentTerm，再次重新选举

选举过程中有两种需要注意的情况：

Candidate发起投票时候广播出去的信息中会带上该选举期的term以及本地日志最后一条的index，其余节点接收到投票要求后，会对比[term, Index]，只有localTerm

如果在选举过程中收到来自其它Leader的AppendEntries RPC。如果该Leader的Term不小于本地的localTerm，则认可该Leader身份的合法性，主动降级为Follower；反之，则维持Candidate身份，继续等待投票结果。

这样保证了新选举出来的leader拥有最新的信息，符合Leader Append-Only规则（Leader从不“重写”或者“删除”本地Log，仅仅“追加”本地Log）。

Log replication过程：

成为新的Leader后，Leader将负责把所有Follower日志同步成与Leader一致状态，并且负责处理所有客户端交互，当新的请求过来时，处理过程如下：

1. Client发送command给Leader

2. Leader追加command至本地log

3. Leader通过AppendEntriesRPC将command发至Follower

4. Follower追加command至本地log，并向Leader返回ok

5. Leader收到超过半数Follower的ok之后，向客户端返回ok，并commit该条日志

6. 通过下一次AppendEntriesRPC将committed日志项通知到Follower

7. Follower收到committed日志项后，commit这条所对应的本地日志项

算法中的重要名词解释：

①term

      从从一次选举开始至下一次选举开始的时间段，是从选举一个leader到其任期结束的时间。是一种用于分辨“过期信息”的逻辑时间，每个节点均维护一个本地term来鉴别接受信息是否过期。

② heartbeat timeout

      主从之间通过AppendEntries RPC（相当于心跳连接）保持连接，heartbeat timeout 是在心跳通信时候的超时，当follower超过这个时间没有来自leader的心跳信息后，follower将自增localTerm，转变成candidate状态投票自己并发起新的选举。

③ election timeout

      election timeout是在发起新一轮选举后发生的，如果在选举时限内未收到超过半数的票，将进入下一个term发起新一轮选举。

④不同的超时时长

     每个节点超时时间在150~300ms之间，各个节点随机设定，以此保证不会因为相等超时时长导致的多种问题（例如两个节点同时发起一个term任期内的选举并各得一半票数的时候，因为超时时间不同，其中一个节点可以先超时而发起下一轮投票，从而得到大多数投票成为leader负责同步状态，从而使系统加速收敛为一致状态 ）。

reference：

1）  http://thesecretlivesofdata.com/raft/

2） https://raft.github.io/