Raft协议是解决分布式一致性的重要解决方案， 不废话，直接开整 ！！！
什么是分布式一致性问题？
比如常见的一主二从， 写数据时，只写一个主节点，然后由主节点 将新写入的数据 同步到从节点。如何保证主节点和从节点拥有相同的数据内容？这就是分布式一致性问题
Raft协议的模型
Raft通过日志复制解决了 数据一致性问题；通过领导选举保证了 leader节点（上面说的主节点）的可用性，无时无刻都会有主节点的存在。
领导选举（主节点选举）
先搞清一个问题，在分布式系统为啥需要leader？
- 分布式系统一定需要一定数量的副本，保证高可用。 Leader就可以协调各个副本和主节点的数据一致性
- leader 可以集中实施策略
- leader负责管理 系统的元数据和命名空间
前提知识
Raft协议中所有节点只有三种状态
- follower （跟随者，理解为群众的意思）
- candidate（候选人）
- leader （主节点）
总体了解
leader会定时向follower发送心跳，表示leader存在，follower无须发起候选。
每个follower会有一个随机超时定时器，一旦这段时间内没有收到leader的心跳，它便会成为候选人，去晋升为leader。
（150~300ms）
正篇
一开始，任何节点都是跟随者状态。如果一个follower在超时范围内没有收到leader的心跳，follwer认为leader以死。于是follower成为candidate。 如下图， A作为 leader 宕机了，假设B超时快一点，B就会成为candidate
之后candidate向其他节点请求获得选票。如下图，Node A，Node C，就即将收到节点B的投票请求。
其他节点发现在此次任期内，没有投过票。于是将票给candidate，同时把 term+ 1。
term，表示任期。每进行一次选举 任期都会 + 1。节点之间的交互都会携带
follower节点成为candidate时便会 term + 1，然后请求发起投票。
follower 收到投票请求，比较收到的term，和自己的term。大于则拒绝请求，并让节点更新 term + 1
candidate集群中大多是票之后，便成为leader。（客户端便开始和新的leader交互）
重复选举的情况
A，B节点同时发现leader心跳超时。A，B都成为候选人，向CD发出投票请求。结果 C,D分别收到A，B。导致AB，都没有达到多数票的要求。
于是各个节点将计时器清零 等待下一轮选举的到来。直到某个候选人脱颖而出！！
日志复制
日志复制才是 Raft协议解决分布式一致性的核心。
现在一个leader 节点A，两个follower 节点B，C。如下
这时一个Client 对 leader发起 set num 5的操作。
leader 写值后，并不提交日志。而是将数值改变 跟随心跳发送给 follower。
follower 收到 改变之后 便进行对应得读写操作。然后随心跳响应返回 ack之类。
leader 收到大多数得节点的成功操作，就会提交日志。并返回响应给client
这样各个节点数据就达到了一致性。
日志正因为是强一致性，各大分布式组件采用并不多，因为当前互联网架构下都流行高性能和可用性。从而也导致Raft的leader 选举反而更受欢迎。
