ZK的设计目标
1.简单的数据结构：共享的树型结构，类似与文件系统，数据存储于内存；
2.可以构建集群：避免单点故障，超过半数就可以对外提供服务 ZAB协议；
3.顺序访问：对于每一个写请求，zk会分配一个全局唯一递增ID，利用这个特性可以实现高级的协调服务；
4.高性能：基于内存操作，服务于非事物请求，适用于读操作为主的场景；
ZK可以做什么
1.数据的发布与订阅 ：通过监听机制
2.命名服务 ：依赖于临时节点
3.负载均衡 ：依赖于临时节点
4.集群服务 ：比如选主，依赖于临时节点 同一个目录下不能创建同名的节点
5.配置的管理：数据存储在内存，但是数据量不大的需求
6.分布式锁 ：两种实现 一种是基于临时节点，一种是基于临时节点+顺序节点 ，后边文章会有比较
7.分布式队列：
ZK的数据模型
一、节点类型:
1.持久节点：会话过期后节点不会被删除
2.临时节点：会话过期后会被删除
节点和会话绑定，当一个客户端和服务端建立会话后，服务端会保存会话的id和过期时间，并启动一个定时任务来判断当前会话有没有过期，所以当链接断开但是会话还没有过期时临时节点也存在。如果不断开链接会话过期的时间是靠客户端向服务端发送心跳来延长过期时间的
3.顺序节点：一个有序节点被分配唯一一个单调递增的整数且不同节点下顺序不相干扰
二、一致性:
zab协议来解决多个节点的最终一致性
三、结构:
数据存储
类似于linux的文件结构，不同的是每个目录下都可以写数据（默认1M）
ZK的监视与通知
客户端假如通过轮序的方式获取 ZK 中的节点数据 效率不高 延迟也会增大；所以ZooKeeper支持对节点的变更进行监听通知的能力。
一次监听事件，只会被触发一次，如果想要监听到znode的第二次变更，需要重新注册监听
客户端设置的每个监视点和会话相关联，如果会话过期，等待中的监视点将会被删除。不过监视点可以跨越不同的服务器保持连接。
节点常见的事件通知
1.session建立成功事件
2.节点添加
3.节点删除
4.节点变更
5.子节点列表变化
ZK的版本
每个 Znode 都有一个版本号，它随着每次数据变化而递增
可以使用版本号来组织并行操作的不一致性
