分布式协议——Paxos、Raft和ZAB
Paxos算法是一种提高分布式系统容错率的一致性算法
Paxos 算法的步骤是这样：
1.首先有两种角色，一个是“提议者”，一个是“接受者”。提议者可以向接受者提出提议，然后接受者表达意见。
2.因为存在多个提议者，如果同时表达意见会出现意见不一致的情况，所以首先需要尽快选出一个领导者，让意见统一。
3.然后领导者会给接受者发出提议，如果一个提议被大多数接受者接纳，这个提议就通过了。
Raft协议
Raft 协议的每个副本都会处于三种状态之一：Leader、Follower、Candidate。
Leader：所有请求的处理者，Leader 副本接受 client 的更新请求，本地处理后再同步至多个其他副本。
Follower：请求的被动更新者，从 Leader 接受更新请求，然后写入本地日志文件。
Candidate：如果 Follower 副本在一段时间内没有收到 Leader 副本的心跳，则判断 Leader 可能已经故障，此时启动选主过程，此时副本会变成 Candidate 状态，直到选主结束。
每一个副本都会维护一个 term，类似于一个逻辑时钟，每发生一个动作就会递增，通过比较每个提议的 term，副本会默认使用最新的 term，防止发生冲突。如果一个 Leader 或者 Candidate 发现自己的 term 不是最新的了，就会自动降级到 Follower，而如果一个 Follower 接收到低于自己当前 term 的提议，就会直接抛弃。
参考：从Paxos到Zookeeper分布式一致性原理与实践
ZAB（Zookeeper Atomic Broadcast）协议是为分布式协调服务Zookeeper专门设计的一种支持奔溃恢复的原子广播协议。
Zookeeper使用ZAB协议来保持集群中各副本之间数据的一致性。
Zookeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal（事务提议）的形式广播到所有的副本进程上去。
ZAB协议保证了：
1.同一时刻集群中只有一个主进程来广播服务的状态变更，这样能够很好地处理客户端大量的并发请求
2.在分布式环境中，顺序执行的状态变更前后会存在一定的依赖关系。因此，ZAB协议保证了一个全局的变更序列被顺序执行。
ZAB协议包括了两种基本的模式：崩溃恢复和消息广播
崩溃恢复：1.如果leader服务器出现奔溃退出或机器重启，或者是集群中已经不存在过半的服务器与该leader服务器保持正常通信，那么在重新开始新一轮的原子广播操作之前，所有进程首先会使用奔溃恢复协议来使彼此达到一个一致的状态，此时整个ZAB流程就会从消息广播模式进入奔溃恢复模式。
消息广播：2.ZAB协议中的消息广播使用的是一个原子广播协议，类似于一个二阶段提交的过程。在整个消息广播过程中，leader服务器会为每个事务请求生成对应的proposal（提案）来进行广播，每个follower服务器在接收到这个事务proposal之后，都会首先讲其以事务日志的形式写到磁盘中，并且在成功写入后反馈给leader服务器一个Ack响应。当leader服务器接收到超过半数follower的Ack响应后，就会广播一个Commit消息给所有的follower服务器以通知其进行事务提交，同时leader自身也会完成对事务的提交。
在ZAB协议的事务编号ZXID设计中，ZXID是一个64位的数字。
其中低32位是一个递增的计数器，对客户端的每个事务请求，leader服务器在产生一个新的事务proposal的时候，都会对该计数器进行+1
其中高32位表示了leader周期的epoch编号，每选举一个新leader，就会从这个新的leader服务器中取得最大事务proposal的ZXID，从中解析出对应的epoch值，对其进行+1
