起源于拜占庭将军问题，感兴趣的同学可以百度下。
下面通过一个问题来说明：现在有个单节点系统，存储一个值，你可以想象成数据库或者一个kv 存储服务器。
客户端发送一个数据 8 ，由于服务端只有一个节点，所以很容易就达成了一致。
现在如果我们的服务器变成了 3 个节点，这个时候如何保证 3个节点达成一致呢？这个问题就是分布式一致性问题。
分布式一致性协议
是指实现分布式一致性的协议，比如 Raft 、Paxos、Gossip 等。
分布式节点的三个状态： follower、 candidate、leader ， 所有节点的初始状态都是 follower 。
Raft 工作过程 Leader 选举如果一个 follower 节点无法监听到 leader 就会等待一段时间（选举 timeout，150~300ms）成为 candidate 进入一个选举期（term），首先投自己一票，然后向起他节点请求投票并重置 选举 timeout（如果在这个 term 其他节点没有投过票就可以投票）， 如果获得半数以上的节点的投票就会成为 leader。
日志复制1.leader 接收客户端写，并写入 log 文件，此时数据是 uncommit 状态。
2. leader 通过心跳（心跳 timeout 定义了星跳周期，一旦超时就会产生新一轮的选举）地同步给所有的 follower，并等待响应，半数以上的 follower 写入log 并响应后，数据变为 commited 状态
3. leader 通过心跳通知所有的 follower ，日志条目是已提交状态。follower 改变节点的值，系统达成一致。
特殊情况 选举过程两个 candidate
election timeout 是随机的，如果凑巧 C 和 D 的 election timeout 相同并且极端情况下，刚好都在本期选举中得到一票，则本次选举没有成功，会重新下一轮选举。
C 和 D 各自先投自己一票，然后向其他节点发起投票请求
由于一期投票中一个节点只能投一次票，C 和 D 同时最多只能各获取 1票
网络分区
多节点的分区会选出一个新的 leader 。
这个时候老的 leader 收到客户端变更后无法同步到半数节点，因此 log 一直为 uncommited 状态。
这个时候分区恢复了，新的 leader 会把心新值通过心跳同步到老的 leader， 老的 leader 因为看到较大的 term 而退化为 follower。
总结
1. leader 选举过程，采用半数以上方式，保证一轮选举中最多只能选出一个 leader。
2. 达成一致的过程采用了经典的 2 阶段提交的方式：第一阶段同步日志，第二阶段提交
