文章目录
1、什么是Raft
Paxos 是论证了一致性协议的可行性，但是论证的过程据说晦涩难懂，缺少必要的实现细节，而且
工程实现难度比较高, 广为人知实现只有 zk 的实现 zab 协议。
Paxos协议的出现为分布式强一致性提供了很好的理论基础，但是Paxos协议理解起来较为困难，
实现比较复杂。
然后斯坦福大学RamCloud项目中提出了易实现，易理解的分布式一致性复制协议 Raft。Java，
C++，Go 等都有其对应的实现之后出现的Raft相对要简洁很多。引入主节点，通过竞选确定主节点。节
点类型：Follower、Candidate 和 Leader。
- Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间（我想称它为“静默时间”），一般为 150ms~300ms；
- 如果在这个时间内没有收到 Leader 的心跳包，就会变成 Candidate（静默期已到，哥们我要出山了），进入竞选阶段；
- 通过竞选阶段的投票多的人成为Leader（当老大了）。
2、Raft相关概念
节点状态：
- Leader（主节点）：接受 Client 更新请求，写入本地后，然后同步到其他副本中。
- Follower（从节点）：从 Leader 中接受更新请求，然后写入本地日志文件。对客户端提供读
请求。 - Candidate（候选节点）：如果 Follower 在一段时间内未收到 leader 心跳。则判断 leader
可能故障，发起选主提议。节点状态从 Follower 变为 Candidate 状态，直到选主结束。
Election Timeout：
选举超时时间（可以被重置）。是节点状态从Follower变为Candidate的时间，是一个150ms～300ms的随机值。
Heartbeat Timeout：
心跳超时时间。Leader节点会以固定的时间间隔定时给Follower节点发送心跳。
Election Term：
选举轮次。初始值为0，当某个节点从Follower 变为 Candidate时该节点的Term会加1。Term值越大表示当前leader越新。
Request Vote：
请求投票，Candidate 在选举过程中发起，收到多数派响应后，成为 Leader。
3、原理解析
Raft提供两个核心过程：日志复制和Leader选举。
3.1、日志复制
1、来自客户端的修改都会被传入 Leader。注意该修改还未被提交，只是写入日志中。
2、Leader 会把修改复制到所有 Follower。
3、Leader 会等待大多数的 Follower 也进行了修改，然后才将修改提交。
4、此时 Leader 会通知的所有 Follower 让它们也提交修改，此时所有节点的值达成一致。
3.2、Leader选举
1、初始阶段，只有 Follower，没有 Leader。Follower A 优先等待一个随机的Election Timeout（竞选超时时间）之后，没收到 Leader 发来的心跳包，因此进入竞选阶段。
2、A 发送投票请求给其它所有节点。
3、其它节点如果在当前Term没有投过票则会对请求进行回复，如果超过一半的节点回复了，那么该 Candidate 就会变成 Leader。
4、之后 Leader 会根据Heartbeat Timeout周期性地发送心跳包给 Follower，Follower 接收到心跳包，会重置Election Timeout。
3.3、Leader节点宕机
当之前选举的Leader A宕机，节点B和节点C在选举超时时间内没有收到Leader的心跳续约包，其中节点B优先结束选举超时时间即变为Candidate。
后续的流程和之前一样，只不过宕机的节点A不会做出任何响应。
3.4、多个Candidate竞争选举
1、如果有多个 Follower 成为 Candidate，并且所获得票数相同，那么就需要重新开始投票。
2、当重新开始投票时，由于每个节点设置的随机竞选超时时间不同，因此下一次再次出现多个Candidate 并获得同样票数的概率很低。
3.5、网络分区处理
1、当出现网络分区后，如果某个分区没有Leader则会进行Leader选举。
2、当网络分区恢复后，多个分区里面的Leader取Term最大的一个作为分区恢复以后整个集群的Leader，然后向其他节点同步自己的数据。
4、总结
Raft是在Paxos协议基础上的一个便于理解，便于实现的分布式一致性协议。也经常被用在分布式系统和软件当中，其中就包括了大名鼎鼎的Redis，两者都是保证了CAP理论中的“AP”。
通过了解也发现Raft的Leader选举和日志复制过程巧妙又有趣，对于入门分布式，以及了解分布式系统面临的问题有很大的帮助。