Zookeeper的应用场景如下：数据发布与订阅（配置文件信息管理）、分布式锁、分布式选举、分布式日志收集、负载均衡、命名服务、集群管理
数据发布与定于（配置文件信息管理）：典型的应用场景为数据库切换。配置信息一般较小，集群中各个节点共享，且数据内容在运行时会动态变化。将配置信息存储在zookeeper集群中，每个节点开机时在zookeeper集群中获取配置信息同时在zookeeper的响应znode上注册watcher监听，当配置信息发生变化时zookeeper会给节点发送watcher通知，客户端再去重新获取。此应用场景下的特点：数据量小、数据内容运行时是实时变化、各机器共享数据。
负载均衡：动态DNS服务为例：当应用的机器在一定规模范围之内时可以使用本地host绑定来实现域名解析。但是当域名变更频繁且规模较大时存在缺陷。此时可以利用zookeeper实现。
命名服务：比如RPC中的服务器列表等。可以通过一个资源引用的方式获得对资源的使用与定位。即为分布式系统中的机器或者服务等提供一个唯一的全局id。在分布式情况下采用数据库组件类似的全局id不方便，且只能保证局部全局唯一。首先根据任务不同类型创建类型节点，当需要申请全局id时，在相应的节点下创建顺序节点，最后返回后与类型拼接在一起就可以实现全局唯一id。若采用UUID实现，每个id过长且意义不明。
集群管理:包括集群的监控与控制，例如当集群增加机器时，在相应的cluster节点下创建一个新的临时节点，客户端在clister注册watcher监听，增加节点后边可以等到变更的通知。
分布式日志系统的管理：传统的架构是将所有需要收集的机器分为不同的组，每个组使用一个日志收集器。需要满足源机器的动态变化以及收集器的动态变化。
在zookeeper中创建一个收集器的根节点root，每一个收集器启动时在root节点下创建一个持久节点（没有使用临时节点，所以为了验证存活性，在每个收集器节点下创建一个状态节点），所有收集器创建结束后系统根据root节点下子节点的数量将日志源机器分为对应的若干组并分配在相应的子节点下。同时每个子节点创建一个status子节点用于记录该收集器得到负载程度及状态信息，每个收集器都会定时的向该节点写入自己的状态信息，通常是进度信息，日志系统根据该节点最后更新时间来判断对应的收集器是否存活。如果某个收集器挂了则将其所有的任务进行转移。若加入节点，转移时可以根据status中的负载程度将任务转移到负载程度较低的节点下；若收集器挂掉，则可以将该收集器下的机器分配到其他负载程度较低的节点下。
Master选举：临时节点。如果通过关系型数据库的话，当Master挂了之后其他节点不会感知。使用zookeeper，每天在根节点下创建一个日期节点，集群中所有的机器同时在该节点下创建一个相同的临时节点，只有一个创建成功，该机器为Master。其他机器注册watcher监听，当Master挂了之后其他机器节点再去重复上述步骤获取Master。
分布式锁：排它锁:所有申请锁的机器，在同一个znode节点下创建同一个子临时节点，同时只有一个机器创建成功，该机器获得锁。当该机器宕机或者锁使用结束后自动删除该节点。其他机器通过watcher获得该通知重新去申请锁。
共享锁：。。。
分布式队列：。。。
分布式屏障：。。。
