想必很多人都听过Paxos算法，它是分布式一致性算法领域的垄断者。但是Paxos算法比较难懂，我几年前看过一次没整明白，后来基本都忘干了。Raft算法可以说是分布式一致性算法领域的后起之秀，比较容易理解。在基于Go语言生态里面，Raft协议应用很广，比如大名鼎鼎的etcd就使用Raft协议实现。
下面我们来介绍Raft协议：
角色
Raft协议一共包含如下3类角色：
Leader（领袖）：领袖由群众投票选举得出，每次选举，只能选出一名领袖；
Candidate（候选人）：当没有领袖时，某些群众可以成为候选人，然后去竞争领袖的位置；
Follower（群众）：这个很好理解，就不解释了。
选举
Leader Election（领导人选举）：简称选举，就是从候选人中选出领袖；
Term（任期）：它其实是个单独递增的连续数字，每一次任期就会重新发起一次领导人选举；
Election Timeout（选举超时）：就是一个超时时间，当群众超时未收到领袖的心跳时，会重新进行选举。
角色变化
初始状态，所有节点都是群众
群众->候选人：定时器先过期，选举开始
候选人->领导者：获得大多数投票
候选人->群众：发现已经有领导者或者更新的任期
候选人->候选人：定时器超时或者进入一轮新的任期
领导者->群众：发现有节点有更高的任期
选举过程
初始时所有节点都是群众，并且各自的选举定时器开始计时。
成为候选人：每个节点都有自己的“超时时间”，因为是随机的，区间值为150~300ms，所以出现相同随机时间的概率比较小，因为节点B最先超时，这时它就成为候选人。
选举领导人：候选人B开始发起投票，群众A和C返回投票，当候选人B获取大部分选票后，选举成功，候选人B成为领袖。
心跳探测：为了时刻宣誓自己的领导人地位，领袖B需要时刻向群众发起心跳，当群众A和C收到领袖B的心跳后，群众A和C的“超时时间”会重置为0，然后重新计数，依次反复。
这里需要说明一下，领袖广播心跳的周期必须要短于“选举定时器”的超时时间，否则群众会频繁成为候选者，也就会出现频繁发生选举，切换Leader的情况。
当领袖B挂掉，群众A和C会的“选举定时器”会一直运行，当群众A先超时时，会成为候选人，然后后续流程和“领导人选举”流程一样，即通知投票 -> 接收投票 -> 成为领袖 -> 心跳探测。
重要：候选人在发起选举的时候会加上当前自己的最新的日志index和term。群众收到选举消息时，会根据这两个字段的信息，判断这个竞选者的日志是不是比自己新，如果是，则赞成选举，否则投反对票。
当出现多个候选者时，两个候选者会同时发起投票，如果票数不同，最先得到大部分投票的节点会成为领袖；如果获取的票数相同，会重新发起新一轮的投票
国外有网站制作一个讲解Raft协议的动画，非常生动，推荐一看。http://thesecretlivesofdata.com/raft/
