ZooKeeper是一个分布式协调服务，其设计目标是将复杂的分布式一致性服务封装成高效的原语集，以简单的接口提供给用户使用。
应用场景命名服务：通过指定的名字获取资源或访服务的地址。如RPC框架的服务地址列表配置管理：分布式部署的配置文件集群管理：通过实时监控znode节点变化来管理集群机器 数据模型
采用多叉树作为数据结构，每个节点都可以存储数据，并拥有唯一的路径标识。
ZK的最小数据单元，由节点状态信息stat和节点存放的数据data两部分组成，可分为四类：
· 持久（PERSISTENT）节点 ：一旦创建就一直存在即使 ZooKeeper 集群宕机，直到将其删除。
· 临时（EPHEMERAL）节点 ：临时节点的生命周期是与 客户端会话（session） 绑定的，会话消失则节点消失 。并且，临时节点只能做叶子节点 ，不能创建子节点。
· 持久顺序（PERSISTENT_SEQUENTIAL）节点 ：子节点名称具有顺序性的持久节点。比如 /node1/app001 、/node1/app002 。
· 临时顺序（EPHEMERAL_SEQUENTIAL）节点 ：子节点名称具有顺序性的临时节点。
ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发时，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去。
SessionSession 可以看作是 ZooKeeper 服务器与客户端的之间的一个 TCP 长连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的 Watcher 事件通知。
集群管理
ZooKeeper 集群中的所有机器通过一个 Leader 选举过程 来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略
当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，就会进入 Leader 选举过程，这个过程会选举产生新的 Leader 服务器。 这个过程大致是这样的：
- Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。Discovery（发现阶段） ：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。Synchronization（同步阶段） :同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后
准 leader 才会成为真正的 leader。
Broadcast（广播阶段） :到了这个阶段，ZooKeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步
Q： ZooKeeper 集群为啥最好奇数台？
A：ZooKeeper 集群存活的服务器个数大于宕掉的服务器数时才可用，即2n和2n-1台服务器都最多允许n-1台宕机，因此没必要多加一台。
ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
