通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。每个 server 都 维护的内存状态镜像以及持久化存储的事务日志和快照。对于 2n+1 台 server，只要有 n+1 台(大多数)server 可用，整个系统保持可用。我们已经了解到，一个 zookeeper 集群如果 要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通 信，基于这个特性，如果向搭建一个能够允许 F 台机器 down 掉的集群，那么就要部署 2*F+1 台服务器构成的 zookeeper 集群。因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台 机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器怪调的情况下进行容灾。 如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上 并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台 server 为 Leader，其它的就作为 follower(这里先不考虑 observer 角色)。 之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过及群众过 半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。
zookeeper通过三种不同的集群角色来组成整个高性能集群的
在 zookeeper 中，客户端会随机连接到 zookeeper 集群中 的一个节点，如果是读请求，就直接从当前节点中读取数据，如果是写请求，那么请求会被转发给 leader 提交事务，
然后 leader 会广播事务，只要有超过半数节点写入成功， 那么写请求就会被提交(类 2PC 事务)
那么问题来了
- 集群中的 leader 节点如何选举出来?
- leader 节点崩溃以后，整个集群无法处理写请求，如何快速从其他节点里面选举出新的 leader 呢?
- leader 节点和各个 follower 节点的数据一致性如何保证
ZAB 协议
ZAB(Zookeeper Atomic Broadcast) 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子 广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现 分布式数据一致性，基于该协议，ZooKeeper 实现了一种 主备模式的系统架构来保持集群中各个副本之间的数据一 致性。
ZAB 协议介绍
ZAB 协议包含两种基本模式，分别是
- 崩溃恢复
- 原子广播
当整个集群在启动时，或者当 leader 节点出现网络中断、 崩溃等情况时，ZAB 协议就会进入恢复模式并选举产生新 的 Leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后(同步指的是数 据同步，用来保证集群中过半的机器能够和 leader 服务器 的数据状态保持一致)，ZAB 协议就会退出恢复模式。 当集群中已经有过半的 Follower 节点完成了和 Leader 状 态同步以后，那么整个集群就进入了消息广播模式。这个 时候，在 Leader 节点正常工作时，启动一台新的服务器加 入到集群，那这个服务器会直接进入数据恢复模式，和
leader 节点进行数据同步。同步完成后即可正常对外提供 非事务请求的处理。
需要注意的是:leader 节点可以处理事务请求和非事务请 求，follower 节点只能处理非事务请求，如果 follower 节 点接收到非事务请求，会把这个请求转发给 Leader 服务器
消息广播的实现原理
如果大家了解分布式事务的 2pc 和 3pc 协议的话(不了解 也没关系，我们后面会讲)，消息广播的过程实际上是一个 简化版本的二阶段提交过程
leader 接收到消息请求后，将消息赋予一个全局唯一的64 位自增 id，叫:zxid，通过 zxid 的大小比较既可以实现因果有序这个特征
leader 为每个 follower 准备了一个 FIFO 队列(通过 TCP协议来实现，以实现了全局有序这一个特点)将带有 zxid的消息作为一个提案(proposal)分发给所有的 follower
当 follower 接收到 proposal，先把 proposal 写到磁盘，写入成功以后再向 leader 回复一个 ack
当 leader 接收到合法数量(超过半数节点)的 ACK 后，leader 就会向这些 follower 发送 commit 命令，同时会在本地执行该消息
当 follower 收到消息的 commit 命令以后，会提交该消息
和完整的 2pc 事务不一样的地方在于，zab 协议不能 终止事务，follower 节点要么 ACK 给 leader，要么抛弃 leader，只需要保证过半数的节点响应这个消息并提交了 即可，虽然在某一个时刻 follower 节点和 leader 节点的 状态会不一致，但是也是这个特性提升了集群的整体性 能。 当然这种数据不一致的问题，zab 协议提供了一种 恢复模式来进行数据恢复
崩溃恢复的实现原理
前面我们已经清楚了 ZAB 协议中的消息广播过程，ZAB 协 议的这个基于原子广播协议的消息广播过程，在正常情况 下是没有任何问题的，但是一旦 Leader 节点崩溃，或者由 于网络问题导致 Leader 服务器失去了过半的 Follower 节 点的联系(leader 失去与过半 follower 节点联系，可能是 leader 节点和 follower 节点之间产生了网络分区，那么此 时的 leader 不再是合法的 leader 了)，那么就会进入到崩 溃恢复模式。崩溃恢复状态下 zab 协议需要做两件事。
选举出新的 leader
数据同步
前面在讲解消息广播时，知道 ZAB 协议的消息广播机制是 简化版本的 2PC 协议，这种协议只需要集群中过半的节点 响应提交即可。但是它无法处理 Leader 服务器崩溃带来的 数据不一致问题。因此在 ZAB 协议中添加了一个“崩溃恢 复模式”来解决这个问题。
那么 ZAB 协议中的崩溃恢复需要保证，如果一个事务 Proposal 在一台机器上被处理成功，那么这个事务应该在 所有机器上都被处理成功，哪怕是出现故障。为了达到这 个目的，我们先来设想一下，在 zookeeper 中会有哪些场 景导致数据不一致性，以及针对这个场景，zab 协议中的 崩溃恢复应该怎么处理。
图中的 C2 就是一个 典型的例 子，在集群 正常运行 过程的某 一个时刻， Server1 是 leader 服 务器，先后广播了消 息 P1、P2、 C1、P3 和 C2.其中当 leader 服 务器把消 息 C2(Com mit 事务 proposal2 )发出后就 立即崩溃 退出了，那 么针对这种情况， ZAB 协议 就需要确 保事务 Proposal2 最终能够 在所有的 服务器上 都能被提 交成功，否 则将会出 现不一致。
当 leader 接收到消 息请求生成 proposal 后就挂 了，其他 follower 并没有收 到此 proposal ，因此经 过恢复模式重新选 了 leader 后，这条 消息是被 跳过的。 此时，之 前挂了的 leader 重 新启动并 注册成了 follower， 他保留了 被跳过消 息的proposal 状态，与 整个系统 的状态是 不一致 的，需要 将其删 除。
ZAB 协议需要满足上面两种情况，就必须要设计一个 leader 选举算法:能够确保已经被 leader 提交的事务 Proposal 能够提交、同时丢弃已经被跳过的事务 Proposal。 针对这个要求
- 如果 leader 选举算法能够保证新选举出来的 Leader 服 务器拥有集群中所有机器最高编号(ZXID 最大)的事务 Proposal，那么就可以保证这个新选举出来的 Leader 一 定具有已经提交的提案。因为所有提案被 COMMIT 之 前必须有超过半数的 followerACK，即必须有超过半数节点的服务器的事务日志上有该提案的 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 清除
总结
ZK之间的协议是ZAB协议，写事务是由leader操作，然后同步到每个节点，有一半的节点返回ack后才算是成功。
主要是leader挂掉后，选举新的leader，和数据同步。
选举leader是过半提交。
选举出来的leader服务器拥有集群中所有机器最高编号(ZXID 最大)的事务 Proposal。
