11.1.1. Zookeeper 概念
Zookeeper 是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。
Zookeeper 提供了一个类似于 Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但
只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与
通知机制
11.1.1. Zookeeper 角色
Zookeeper 集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种
11.1.1.1. Leader
1. 一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader，它会发起并维护与各 Follwer
及 Observer 间的心跳。
2. 所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器。 只要有超过
半数节点（不包括 observeer 节点） 写入成功，该写请求就会被提交（类 2PC 协议）。
11.1.1.2. Follower
1. 一个 Zookeeper 集群可能同时存在多个 Follower，它会响应 Leader 的心跳，
2. Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理，
3. 并且负责在 Leader 处理写请求时对请求进行投票
11.1.1.3. Observer
角色与 Follower 类似，但是无投票权。 Zookeeper 需保证高可用和强一致性，为了支持更多的客
户端，需要增加更多 Server； Server 增多，投票阶段延迟增大，影响性能； 引入 Observer，
Observer 不参与投票； Observers 接受客户端的连接，并将写请求转发给 leader 节点； 加入更
多 Observer 节点，提高伸缩性，同时不影响吞吐率
11.1.1.1. ZAB 协议
事务编号 Zxid（事务请求计数器+ epoch）
在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息广播协议） 协议的事务编号 Zxid
设计中， Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器， 针对客户端每
一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期 epoch 的编号， 每个当选产生一个新
的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的 ZXID，并从中读取
epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。
Zxid（Transaction id） 类似于 RDBMS 中的事务 ID，用于标识一次更新操作的 Proposal（提议）
ID。为了保证顺序性，该 zkid 必须单调递增