1.什么是ZAB协议?
支持
崩溃恢复的原子广播协议，主要用于实现数据一致性
ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。
基于该协议，zookeeper中实现了一种
主备模式的系统架构来保持集群中各个副本之间数据一致性
其实zookeeper的就在崩溃恢复和消息广播这两个模式之间进行切换。当 Leader 服务可以正常使用，就进入消息广播模式，当 Leader 不可用时，则进入崩溃恢复模式。
主备模式
在上图中有多个客户端向Leader节点发起写入数据操作，Leader节点接收到数据之后将数据备份到多个Slaver中，从而保证数据一致性。
原子广播
1. 客户端首先向zookeeper任意节点发起写请求（事务）。
2. 如果接收的节点是Fellower/Observer类型，就将请求转发给Leader节点。
3. Leader节点接收到消息之后对消息进行处理
1. Leader节点对每条消息（事务）生成一个对应的zxid（全局唯一，递增）
2. 将带有zxid的消息包装成一个proposal转发给所有的Follower节点。
4. Follower将proposal这个事务写到磁盘，将结果（ack）返回给leader。
5. Leader节点统计ack数量。
1.如果有一半以上的节点返回成功，则向所有的Follower节点（包括自己）发送commit消息提交事务，并且给Observer发送INFORM消息。
2.如果ack数量小于一半则发送rollback消息进行事务回滚。
6. 最后返回给客户端
简单解释
其实一个写请求就相当于mysql的一个事务
我们将事务发送到每个Follow节点上，节点如果成功操作就返回ack信息
只要成功操作节点的数量大于一半就将事务提交（commit）
否则的话就将事务进行回滚（rollback）
崩溃恢复
实际上，Leader 服务器处理或丢弃事务都是依赖着 ZXID 的，那么这个 ZXID 如何生成呢？
ZXID（64位）：低32位表示消息计数器（自增），高32位（epoch编号），每次leader得到一个事务都会为该事务生成一个ZXID
Epoch（32位）：每产生一个新的leader,那么epoch会+1
将Leader节点宕机或者失去了过半的follower节点的联系时就进入崩溃恢复模式
崩溃存在以下两种状况
- Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃
针对这种情况ZAP定义了：已经被处理的消息不能丢失
因为每次提交的事务都有一个zxid（全局唯一，递增），因此我们只需要找出所有机器内zxid最大的事务（既该事务是最后一个被提交的事务）并且把存放该zxid的机器选举为leader即可
还可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。
-
当leader收到事务请求，并且还没有发起事务投票之前，leader宕机。
也就是只有leader服务器中有该事务，但是事务随着leader的宕机被丢弃掉了
事务投票之前
针对这种情况ZAP定义了：已经被丢弃的消息不能再次出现
之前宕机的leader节点重新启动之后若再次被选为Leader，要把之前没有commit的事务重新commit，而当前的epoch大于该事务的epoch所以事务会被丢弃而不会被重新加载。也就是只有当事务zxid的epoch和当前的epoch相同时，事务才会被提交
