高效且可靠的分布式协调服务。解决分布式一致性问题
统一命名服务、配置管理服务、分布式锁服务。
使用： 比如配置文件统一，比如通知负载均衡协调。
ZooKeeper 特性：
顺序一致性： 同客户端发起的事物请求，最终将严格的按照其发起顺序被应用到 ZooKeeper 中去。
原子性 ： 所有事物的请求处理结果在整个集群中所有机器是一直的。 要么都成功，要么都没有。
单一视图 ： 所有客户端看到的数据模型是一致的。
可靠性 ： 一旦服务端成功的应用了一个事物，并完成对客户端的响应，那么该事物所引起的状态变会被永久保存。除非更改
实时性 :
ZooKeeper 好的原因：
1 高性能：内存处理 （传输 Netty）
2 构建集群：Watch发送包少。
3 监听强大、Watch 机制。
4 高可用、Leader 选举
ZooKeeper 压力测试：
三节点、五节点、七节点性能效率。
创建100W节点用时：15.0秒。
删除100W节点用时：13.8秒。
设置100W节点用时：90.0秒。
读取100W节点用时：50.5秒。
客户端测试
创建断开。1000节点用时：5.6 秒，全部 watch 成功到达。
方法锁排它锁。
一万次 结果： 66.8 秒，成功。
Watch 监听节点：
1 创建临时节点
2 监听临时节点
3 删除临时节点 产生 Watch - 走 1
一万次 结果： 68.5 秒，成功。
ACL 权限控制，增删改查 和设置 节点 ACL 权限。
ZAB 协议 原子消息广播 同一时刻只有一个主进程来广播服务器状态变更
ZooKeeper 集群角色
1 Leader 处理 所有事物请求，所有写操作，为客户单提供读写服务。
Leader服务器负责将一个客户端请求转换成一个事物（ProPosal ），并将事物分发给所有 Follow 服务器。之后等待 Follow 服务器反馈，一旦超过半数+1进行了反馈，那么Leader会再次向所有Follower 分发 Commit 消息。要求提交。
（SID ZXID） ，先 ZXID , 后比SID。
在新一轮原子广播事物前，一定会先选举Leader。当超过半数进行消息广播、崩溃恢复、
2 Follower 为客户端提供度读服务，写服务/事物请求移交给 Leader。 不参与投票
3 Observer 提供读服务，写服务/事物请求移交给 Leader。 不参与投票
ZooKeeper 会话（Session）
一个客户端连接是指 客户端和服务端一个 TCP 长连接。 ZooKeeper 默认对外端口2181. 客户端与ZK连接时候会声明生命周期。通过 TCP 连接客户端通过心跳检测与服务器保持会话。 还能接受服务器的 Watch 事件通知。 在声明的SessionTimeout 时间内可以断开后重连而不清除数据。
Curator ——ZooKeeper 的更方便的客户端。 （方便监听、分布式锁）使用 Curator 同步分布式。
Barrier 分布式屏障。
应用场景为一个队列所有的元素都必须全部到达后方可进行统一安排。
DistributedBarrier.setBarrier() 设置
DistributedBarrier.waitOnBarrier() 等待Barrier释放
DistributedBarrier.removeBarrier() 释放Barrier
DistributedDoubleBarrier.enter() 等待线程达到数量所有成员同时触发进入
DistributedDoubleBarrier.leave() 再次等待所有成员。
ZK 节点特性
PERSISTENT：持久节点
EPHEMERAL：临时节点不允许创建子节点。
SEQUENTIAL：节点名末尾追加一个10位数的单调递增的序号同一个节点的所有子节点序号是单调递增的
PERSISTENT_SEQUENTIAL：持久 且 追加 10位数
EPHEMERAL_SEQUENTIAL： 临时 且 追加 10位数
节点属性：
czxid（Create） 节点被创建时的事物ID
mzxid （Modified） 最后一次被更新的事物ID
ctime 创建时间
mtime 修改时间
version 数据节点版本。
cversion 子节点版本号
aversion 节点 ACL 版本号
ephemeralOwner 创建该临时节点的会话的 sessionId。如果是持久节点此为0
dataLength 数据内容长度
numChildren 当前节点的子节点个数
pxzid 子节点列表变更通知，（内容不会）
ZooKeeper 事物
Watch 特性总结
1 一次性
一旦一个 Watcher 被触发，ZooKeeper 都会将其从相应的存储中移除。 （需要重复注册Watch）
2 客户端串行执行
因为串行，所以不要因为一个 Watch 的处理逻辑影响整个客户端回调。
3 轻量
通知状态 - KeeperState、事件类型 - EventType、节点路径 - Path 封装成一个 WatchedEvent 对象
Leader 和 Follower 服务器启动交互过程
1 Leader 选举后 创建 Leader 和 Follower 服务器
2 Leader 服务器 启动 Follower 的接收器 LearnerCnxAcceptor
ZK 运行期间，leader 需要与 其他 机器保持连接判断存活情况。
LearnerCnxAcceptor 接收器用于接受所有非 Leader 的连接
3 Learner 服务器开始和 Leader 建立连接
4 Leader 服务器 创建 LearnerHandler
每个 LearnerHandler 实例都对应了一个 Leader 与 Learner 服务器的连接
5 向 Leader 注册
当和 Leader 建立起连接后， Learner 就会开始向 Leader 进行注册。发送自己的基本信息。（SIZ,ZXID）我们称之为 LearnerInfo。
6 Leader 解析Learner 信息，计算新的 epoch
与 Learner 交互解析对应的 ZXID。 如果 Leader 比 Learner 小 则更新 Leader ZXID（ 算法过程中有个参数加一 ）（SID ZXID 事物最高ID）
LearnerHandler 等待投票。且半数后会第二次催促投票。
7 发送 Leader 状态
计算新的 epoch 之后， Leader 将消息以一个 LeaderINFO 消息发送给 Learner。
8 Learner 发送 ACK 消息
Follower 在受到来自 Leader 的 LeaderINFO 消息后，然后向 Leader 反馈一个相应。
9 数据同步
10 启动 Leader 和 Learner 服务器。
Leader 和 Follower 启动
1 创建并启动会话
2 初始化 ZooKeeper 的请求处理链
3 注册 JMX 服务
服务器启动期 Leader 选举
1 每个 Server 发起一个投票先投自己，然后将投票发送给其他所有机器
2 接收来自各个服务器的投票。判断是否本轮投票，是否是 LOOKING 状态服务器。
3 处理投票。
1) 检查 ZXID.
2) 如果相同，检查 myid （SID）
3) 发送结果。
4 统计投票
每轮投票都会判断自己是否已经有过半机器接收到相同投票信息。
5 改变服务器状态。
一旦确定了 Leader 先更新自己的状态， 如果是 Follower 就变更为 FOLLOWING,如果是Leader 就变更为 LEADING
服务器运行期间 Leader 选举。
一旦选出了一个 Leader 那么所有服务器角色一般不会发生变化。当有Leader宕机时候才会进入新一轮选举
1 变更状态
1) 当 Leader 挂了后，余下的非 OBserver 服务器 变更自己的状态为 LOOKING。然后进入Leader 选举流程
2 同启动期投票
新节点加入时，当他试图进行选举会被告知当前服务器的 Leader 信息。对于该机器来说，仅仅需要和Leader 建立连接，并进行状态同步即可。
ZK 会话 。P352