Md2All export document
什么是ZooKeeperZooKeeper的数据结构监听器ZooKeeper应用统一配置管理分布式锁集群状态主备Master动态选举
什么是ZooKeeper
ZooKeeper是Apache社区顶级的开源项目，主要用于分布式系统，可以用ZooKeeper来做：统一配置管理、统一命名服务、分布式锁、集群管理。
ZooKeeper的数据结构
跟Unix文件系统非常相似，可以看做是一棵树，每个节点叫做ZNode。每个节点通过路径来标识。
ZNode节点分为两种类型：
- 短暂/临时(Ephemeral)
- 持久（Persistent）
区别：当客户端与服务端断开连接后，前者所创建的ZNode会自动删除；后者会保留。
监听器
监听器监听节点ZNode的变化，主要有以下两项：
- 监听ZNode节点的数据变化
- 监听子节点的增减变化
前者是监听某个节点数据本身是否发生了变化，后者监听某个节点的子节点是否发生了增减。ZooKeeper通过这两个监听就能完成很多工作了。
ZooKeeper应用
统一配置管理
典型场景：各个独立的小系统监听使用同一份配置文件。
比如我们现在有三个系统A、B、C，他们有三份配置，分别是ASystem.yml、BSystem.yml、CSystem.yml，然后，这三份配置又非常类似，很多的配置项几乎都一样。
此时，如果我们要改变其中一份配置项的信息，很可能其他两份都要改。很容易遗漏。
于是，我们希望把ASystem.yml、BSystem.yml、CSystem.yml相同的配置项抽取出来成一份公用的配置common.yml，并且即便common.yml改了，系统A、B、C能够自动获取到更改，分别进行自我更新。
做法：可以将common.yml这份配置放置到ZooKeeper的某个ZNode节点中，系统A、B、C监听该ZNode节点有无变更，如果变更了，及时自我响应处理。
分布式锁
可以使用ZooKeeper来实现分布式锁。
系统A、B、C都去访问/locks节点
访问的时候会创建带顺序号的临时/短暂(EPHEMERAL_SEQUENTIAL)节点，比如，系统A创建了id_000000节点，系统B创建了id_000002节点，系统C创建了id_000001节点。
创建临时节点时，节点的顺序号是逐渐递增的，多个访问总会有时间先后顺序，先创建的临时节点序号低。
接着，每个系统访问/locks拿到所有子节点，并判断自己创建的是不是最小的子节点。
-
如果是，则拿到锁。
释放锁：执行相关业务完成后，把创建的节点给删除掉。
-
如果不是，则监听比自己小1的节点的变化，直到自己是最小的临时节点。
集群状态
一般用在集群操作系统中，比如云计算等领域。
如一个云操作系统OpenStack，节点共有100+，实时监控每个节点VM是否正常在线，如果不在需要及时上报告警。
比如节点A会有client守护进程，写心跳到ZooKeeper的ZNode X来维持它临时节点的存在；如果节点A宕机断电等异常场景下，肯定不会写心跳上报Zookeeper状态，临时节点超期就会自动删除。那么，其他监控这个ZNode X父节点的就会发现异常，并作出响应。
可以感知节点的上下线变化。把每个节点VM换成每个独立服务也是一样的。
主备Master动态选举
原理也很简单，如果想要实现动态选举Master的功能，Znode节点的类型是带顺序号的临时节点(EPHEMERAL_SEQUENTIAL)就好了。
Zookeeper会每次选举最小编号的作为Master，如果Master挂了，自然对应的Znode节点就会删除。然后让新的最小编号作为Master，这样就可以实现动态选举的功能了。
一般在某个核心服务主备部署场景下很有用，主服务和备服务一般部署在不同机器上，然后分别向ZooKeeper某个ZNode创建子临时节点（带顺序号），并监控该ZNode的变化。临时节点小的为主服务，大的为备服务。
一般是一主一备，或者一主多备部署。
当异常发生时，主服务挂掉，主服务的临时节点也会自动删除，其他服务会选择新的最小编号作为Master，某个备升级成Master。当原来的主服务修复后，会重新创建子临时节点，这时顺序号比较大，作为新的备服务。这样就大大提高了服务的可靠性。