系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口，例如 JMX 接口，来获取一些运行时的信息。引入 ZooKeeper 之后，就不用自己实现一套方案了，只要将这些信息存放到指定的 ZooKeeper 节点上即可。
注意：
在上面提到的应用场景中，有个默认前提——数据量很小，但是数据更新可能会比较快的场景。
这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。
命名服务（Naming Service）命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称它们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用 ZooKeeper 提供的创建节点的 API，能够很容易创建一个全局唯一的path，这个 path 就可以作为一个名字。
阿里巴巴集团开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务，维护全局的服务地址列表。在 Dubbo 的实现中：
1.服务提供者在启动的时候，向 ZooKeeper 上的指定节点 /dubbo/${serviceName}/providers 目录下写入自己的 URL 地址，这个操作就完成了服务的发布。
2.服务消费者启动的时候，订阅 /dubbo/${serviceName}/providers 目录下的提供者 URL 地址， 并向 /dubbo/${serviceName} /consumers 目录下写入自己的 URL 地址。
注意：
所有向 ZooKeeper 上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。
另外，Dubbo 还有针对服务粒度的监控。方法是订阅 /dubbo/${serviceName} 目录下所有提供者和消费者的信息。
分布式通知/协调ZooKeeper 中特有 Watcher 注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对 ZooKeeper 上同一个 Znode 进行注册，监听 Znode 的变化（包括 Znode 本身内容及子节点的），其中一个系统 Update 了 Znode，那么另一个系统能够收到通知，并作出相应处理。
另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来，而是通过 ZooKeeper 上某个节点关联，大大减少系统耦合。
另一种系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了 ZooKeeper 上某些节点的状态，而 ZooKeeper 就把这些变化通知给它们注册 Watcher 的客户端，即推送系统。于是，作出相应的推送任务。
另一种工作汇报模式：一些类似于任务分发系统。子任务启动后，到 ZooKeeper 来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回这个临时节点）。这样任务管理者就能够实时知道任务进度。
分布式锁分布式锁主要得益于 ZooKeeper 为我们保证了数据的强一致性。锁服务可以分为两类：一类是保持独占，另一类是控制时序。
所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把 ZooKeeper 上的一个 Znode 看作是一把锁，通过 create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。
控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已经预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL 来指定）。ZooKeeper 的父节点（/distribute_lock）维持一份 sequence，保证子节点创建的时序性，从而也形成了每个客户端的全局时序。
1.由于同一节点下子节点名称不能相同，所以只要在某个节点下创建 Znode，创建成功即表明加锁成功。注册监听器监听此 Znode，只要删除此 Znode 就通知其他客户端来加锁。