Zookeeper 高可用、高性能且一致的开源协调服务，它提供了一项基本服务：统一命名服
务、、布式协调、存储数据、监听与通知等功能
官网：http://zookeeper.apache.org/
源码：https://github.com/apache/zookeeper
Zookeeper 特性：
Zookeeper是一个由多个server组成的集群
一个leader，多个follower
每个server保存一份数据副本
全局数据一致
分布式读follower，写由leader实施
更新请求转发，由leader实施
更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
数据更新原子性，一次数据更新要么成功，要么失败
全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
实时性，在一定事件范围内，client能读到最新数据
Session会话：
客户端会话，客户端和服务端建立一个TCP长连接 org.apache.zookeeper.ClientCnxn
数据模型
zookeeper的数据模型和文件系统类似，每一个节点称为：znode. 是zookeeper中的最小数据单元。每一个znode上都可以
保存数据和挂载子节点。 从而构成一个层次化的属性结构
节点特性
- 持久化节点 (PERSISTENT) ： 节点创建后会一直存在zookeeper服务器上，直到主动删除
- 持久化有序节点(PERSISTENT_SEQUENTIAL ) ：每个节点都会为它的一级子节点维护一个顺序
- 临时节点(EPHEMERAL) ： 临时节点的生命周期和客户端的会话保持一致。当客户端会话失效，该节点自动清理
- 临时有序节点 (EPHEMERAL_SEQUENTIAL)： 在临时节点上多一个顺序性特性
**注意:**创建znode时设置顺序标识，znode名称后会附加一个值
顺序号是一个单调递增的计数器，由父节点维护 在分布式系统中，
顺序号可以被用于为所有的事件进行全局排序，
这样客户端可以通过顺序号推断事件的顺序
数据模型类型liunx文件模型,树形结构
Znode 结构：
Stat：状态信息、版本、权限相关
状态属性 | 说明 |
czxid | 节点创建时的zxid |
mzxid | 节点最新一次更新发生时的zxid |
ctime | 节点创建时的时间戳. |
mtime | 节点最新一次更新发生时的时间戳. |
dataVersion | 节点数据的更新次数. |
cversion | 其子节点的更新次数 |
aclVersion | 节点 ACL(授权信息)的更新次数 |
ephemeralOwner | 如果该节点为 ephemeral 节点,ephemeralOwner 值表示与该节点绑定的 |
session id. 如果该节点不是 ephemeral 节点,
ephemeralOwner 值为 0 |
|dataLength | 节点数据的字节数. |
| numChildren | 子节点个数 |
ACL(Access Control List)
org.apache.zookeeper.ZooDefs
内置的 ACL schemes：
world：默认方式，相当于全世界都能访问
auth：代表已经认证通过的用户(cli 中可以通过 addauth digest user:pwd 来添加当
前上下文中的授权用户)
digest：即用户名:密码这种方式认证，这也是业务系统中最常用的
ip：使用 Ip 地址认证
zookeeper提供控制节点访问权限的功能，用于有效的保证zookeeper中数据的安全性。避免误操作而导致系统出现重大事故。
ACL 支持权限：
CREATE: 能创建子节点
READ：能获取节点数据和列出其子节点
WRITE: 能设置节点数据
DELETE: 能删除子节点
ADMIN: 能设置权限
watcher
zookeeper提供了分布式数据发布/订阅,zookeeper允许客户端向服务器注册一个watcher监听。当服务器端的节点触发指定事件的时候会触发watcher。服务端会向客户端发送一个事件通知
watcher的通知是一次性，一旦触发一次通知后，该watcher就失效
ZAB 协议
ZAB 协议：Zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同
步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广
播模式。当服务启动或者在领导者崩溃后，Zab 就进入了恢复模式，当领导者被选举出
来，且大多数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保
证了 leader 和 server 具有相同的系统状态。一旦 leader 已经和多数的 follower 进行了状态
同步后，他就可以开始广播消息了，即进入广播状态。
这时候当一个 server 加入 zookeeper 服务中，它会在恢复模式下启动，发现 leader，并和
leader 进行状态同步。待到同步结束，它也参与消息广播。
Zookeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的
followers 支持。
广播模式需要保证 proposal 被按顺序处理，因此 zk 采用了递增的事务 id 号(zxid)来保证。
所有的提议(proposal)都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 为的数字，它
高 32 位是 epoch 用来标识 leader 关系是否改变，每次一个 leader 被选出来，它都会有一
个新的 epoch。低 32 位是个递增计数。
当 leader 崩溃或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，恢复模式需要
重新选举出一个新的 leader，让所有的 server 都恢复到一个正确的状态。
Leader 选举：
LOOKING, FOLLOWING, LEADING, OBSERVING
