Raft协议
1.Raft简介
Raft是由Stanford提出的一种更易理解的一致性算法，意在取代目前广为使用的Paxos算法。关于Raft的原理，建议先看看：动画版Raft讲解
2.Raft原理
在Raft中，每个结点会处于下面三种状态中的一种：
- follower：所有结点都以follower的状态开始，如果没收到leader消息则会变成candidate状态。
- candidate：会向其他结点“拉选票”，如果得到大部分的票则成为leader。这个过程就叫做Leader选举(Leader Election)
- leader：所有对系统的修改都会先经过leader。每个修改都会写一条日志(log entry)。leader收到修改请求后的过程如下，这个过程叫做日志复制(Log Replication)：
Leader Election详解
当follower在选举超时时间(election timeout)内未收到leader的心跳消息(append entries)，则变成candidate状态。为了避免选举冲突，这个超时时间是一个150~300ms之间的随机数。
成为candidate的结点发起新的选举期(election term)去“拉选票”：首先它重置自己的计时器，并投自己一票，然后发送 Request Vote消息“拉票”。
如果接收结点在新term内没有投过票那它就会投给此candidate，并重置它自己的选举超时时间。（就是一个election term没投过票都会投）
candidate拉到大部分选票就会成为leader，并定时发送心跳——Append Entries消息，去重置各个follower的计时器。当前Term会继续直到某个follower接收不到心跳并成为candidate。
如果不巧两个结点同时成为candidate都去“拉票”怎么办？这时会发生Splite Vote情况。两个结点可能都拉到了同样多的选票，难分胜负，选举失败，本term没有leader。
之后又有计时器超时的follower会变成candidate，将term加一并开始新一轮的投票。
Log Replication详解
当发生改变时，leader会复制日志给follower结点，这也是通过Append Entries心跳消息完成的。
leader复制日志到所有follower结点(replicate entry)
大部分follower响应时，leader才提交日志
然后通知所有follower，结点日志已提交
所有follower也提交日志
现在整个系统处于一致的状态