数据模型
在根节点下挂很多子节点(树型)，使用了 znode 作为数据节点，znode 是 zookeeper 中的最小数据单元，每个 znode 上都可以保存数据，同时还可以挂载子节点，形成一个树形化命名空间。
每个 znode 都有自己所属的 节点类型 和 节点状态。
节点类型可以分为 持久节点、持久顺序节点、临时节点 和 临时顺序节点。
- 持久节点：一旦创建就一直存在，直到将其删除。
- 持久顺序节点：维护顺序性
- 临时节点：临时节点的生命周期是与 客户端会话 绑定的，会话消失则节点消失 。临时节点 只能做叶子节点 ，不能创建子节点。
- 临时顺序节点：维护顺序性
节点状态中包含了很多节点的属性比如 czxid 、mzxid 等等
- czxid：Created ZXID，该数据节点被 创建 时的事务ID。
- mzxid：Modified ZXID，节点 最后一次被更新时 的事务ID。
会话
zk 客户端和服务端是通过 TCP 长连接 维持的会话机制
Watcher机制
Watcher 为事件监听器，是 zk 非常重要的一个特性，很多功能都依赖于它，它有点类似于订阅的方式，即客户端向服务端 注册 指定的 watcher ，当服务端符合了 watcher 的某些事件或要求则会 向客户端发送事件通知 ，客户端收到通知后找到自己定义的 Watcher 然后 执行相应的回调方法 。
Zookeeper的几个典型应用场景
选主
分布式锁
命名服务
提到过 zookeeper 是通过 树形结构 来存储数据节点的，那也就是说，对于每个节点的 全路径，它必定是唯一的，我们可以使用节点的全路径作为命名方式了。而且更重要的是，路径是我们可以自己定义的
集群管理和注册中心
我们可以为每条机器创建临时节点，并监控其父节点，如果子节点列表有变动（我们可能创建删除了临时节点），那么我们可以使用在其父节点绑定的 watcher 进行状态监控和回调。
至于注册中心也很简单，我们同样也是让 服务提供者 在 zookeeper 中创建一个临时节点并且将自己的 ip、port、调用方式 写入节点，当 服务消费者 需要进行调用的时候会 通过注册中心找到相应的服务的地址列表(IP端口什么的) ，并缓存到本地(方便以后调用)，当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从地址列表中取一个服务提供者的服务器调用服务。
当服务提供者的某台服务器宕机或下线时，相应的地址会从服务提供者地址列表中移除。同时，注册中心会将新的服务地址列表发送给服务消费者的机器并缓存在消费者本机
