ZAB（Zookeeper Atomic Broadcast） 协议是为分布式协 调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子 广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现 分布式数据一致性，基于该协议，ZooKeeper 实现了一种 主备模式的系统架构来保持集群中各个副本之间的数据一 致性
- 崩溃恢复
- 原子广播
当整个集群在启动时，或者当 leader 节点出现网络中断、 崩溃等情况时，ZAB 协议就会进入恢复模式并选举产生新 的Leader，当 leader服务器选举出来后，并且集群中有过 半的机器和该leader节点完成数据同步后（同步指的是数 据同步，用来保证集群中过半的机器能够和leader服务器 的数据状态保持一致），ZAB协议就会退出恢复模式。 当集群中已经有过半的 Follower 节点完成了和 Leader 状 态同步以后，那么整个集群就进入了消息广播模式。这个 时候，在Leader节点正常工作时，启动一台新的服务器加 入到集群，那这个服务器会直接进入数据恢复模式，和 leader 节点进行数据同步。同步完成后即可正常对外提供 非事务请求的处理
消息广播的实现原理
- leader 接收到消息请求后，将消息赋予一个全局唯一的 64位自增id，叫：zxid，通过zxid的大小比较既可以实 现因果有序这个特征
- leader为每个follower准备了一个FIFO队列（通过TCP 协议来实现，以实现了全局有序这一个特点）将带有zxid
的消息作为一个提案（proposal）分发给所有的follower - 当follower接收到proposal，先把proposal写到磁盘， 写入成功以后再向leader回复一个ack
- 当leader接收到合法数量（超过半数节点）的ACK后， leader就会向这些follower发送commit命令，同时会 在本地执行该消息
- 当 follower 收到消息的 commit命令以后，会提交该消息
投票过程
leader 的投票过程，不需要 Observer 的 ack，也就是 Observer不需要参与投票过程，但是Observer必须要同 步 Leader 的数据从而在处理请求的时候保证数据的一致性
崩溃恢复(数据恢复)
ZAB 协议的这个基于原子广播协议的消息广播过程，在正 常情况下是没有任何问题的，但是一旦 Leader 节点崩溃， 或者由于网络问题导致 Leader 服务器失去了过半的Follower节点的联系（leader失去与过半follower节点联 系，可能是leader节点和follower节点之间产生了网络分 区，那么此时的leader不再是合法的leader了），那么就 会进入到崩溃恢复模式。在ZAB协议中，为了保证程序的 正确运行，整个恢复过程结束后需要选举出一个新的 Leader 为了使 leader 挂了后系统能正常工作，需要解决以下两 个问题
-
已经被处理的消息不能丢失 当 leader 收到合法数量 follower 的 ACKs 后，就向 各个 follower 广播 COMMIT 命令，同时也会在本地 执行 COMMIT 并向连接的客户端返回「成功」。但是如 果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行都这条消息
处理流程
leader 对事务消息发起 commit 操作，但是该消息在 follower1 上执行了，但是 follower2 还没有收到 commit， 就已经挂了，而实际上客户端已经收到该事务消息处理成
功的回执了。所以在zab协议下需要保证所有机器都要执 行这个事务消息 - 被丢弃的消息不能再次出现 当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的。 此时，之前挂了的 leader 重新启动并注册成了 follower，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的，需要将其删除。
ZAB 协议需要满足上面两种情况，就必须要设计一个 leader 选举算法：能够确保已经被 leader 提交的事务 Proposal能够提交、同时丢弃已经被跳过的事务Proposal。 针对这个要求 1. 如果 leader 选举算法能够保证新选举出来的 Leader 服 务器拥有集群中所有机器最高编号（ZXID最大）的事务 Proposal，那么就可以保证这个新选举出来的Leader一 定具有已经提交的提案。因为所有提案被 COMMIT 之 前必须有超过半数的 follower ACK，即必须有超过半数 节点的服务器的事务日志上有该提案的 proposal，因此，只要有合法数量的节点正常工作，就必然有一个节点保 存了所有被 COMMIT 消息的 proposal 状态 另外一个，zxid是64位，高32位是epoch编号，每经过 一次 Leader 选举产生一个新的 leader，新的 leader 会将 epoch 号+1，低 32 位是消息计数器，每接收到一条消息 这个值+1，新 leader选举后这个值重置为0.这样设计的好 处在于老的leader挂了以后重启，它不会被选举为leader， 因此此时它的 zxid 肯定小于当前新的 leader。当老的 leader 作为 follower 接入新的 leader 后，新的 leader 会 让它将所有的拥有旧的 epoch 号的未被 COMMIT 的 proposal 清除
