ZooKeeper是一个典型的发布/订阅模式的分布式数据管理与协调框架，基于对ZAB算法的实现，该框架能够很好地保证分布式环境中数据的一致性。如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等
数据发布/订阅
- 即所谓的配置中心，发布者将数据发布到ZooKeeper的一个或一系列节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。
- 推拉相结合的方式：客户端向服务端注册自己需要关注的节点，一旦该节点的数据发生变更，服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知之后，需要主动到服务器端获取最新的数据。
- 通用的配置：机器列表信息、运行时的开关配置、数据库配置信息等
负载均衡
- 动态DNS方案：可以避免域名数量无限增长带来的集中式维护的成本；在域名变更的情况下，也能够避免因逐台机器更新本地HOST而带来的繁琐工作。
命名服务
- 被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等
- 全局唯一ID
分布式协调/通知
- 对于一个在多台机器上部署运行等应用而言，通常需要一个协调者来控制整个系统的运行流程，例如分布式事务的处理、机器间的互相协调等
- ZooKeeper中特有的Watcher注册与异步通知机制，能够很好地实现分布式环境下不同机器的协调与通知，不同的客户端都对ZooKeeper上同一个数据节点进行Watcher注册，监听数据节点的变化。
集群管理
- 分布式日志收集系统：收集分布在不同机器上的系统日志
- 在线云主机管理
Master选举
- 广告投放系统后台与ZooKeeper交互
分布式锁
- 排他锁（写锁或独占锁）
- 共享锁（读锁）
/shared_lock/[Hostname]-请求类型-序号
版本1：关注全局（shared_lock）的子列表变更情况，每次通知只会对序号最小的节点有影响，会造成大量无用的Watcher通知和子节点列表获取
版本2：每个节点对应的客户端只需要关注比自己序号小的那个相关节点的变更情况
读请求：向比自己序号小的最后一个写请求节点注册Watcher监听
写请求：向比自己序号小的最后一个节点注册Watcher监听
分布式队列
- FIFO
- Barrier：分布式屏障，一个队列的元素必须都集聚后才能统一进行安排，否则一致等待
