Zookeeper使用的范围十分广，我接触过的好几个场景都使用了zookpper作为注册中心，如kafka消息队列，dubbo分布式服务，Hadoop namenode选举……是个名副其实的 “流量” 呀~
以下是个人的一些小小的理解~
Dubbo如何使用zookeeper：
zookeeper的数据节点都提供了一些简单的API供客户端调用，如增删改查等，注册到zookeeper上的程序端都可以操作这些节点，这是zookeeper作为dubbo注册中心的先决条件。
1. 服务端连接zookeeper之后，推送自己的服务信息（名称，地址等），此信息保存成树状形式，每一个节点都设置了监听事件。
2. 消费者端连接zookeeper之后，根据配置的服务信息将会读取到zookeeper上保存的数据节点，同时将该消费者加入watcher列表，当数据节点数据发生改变时，将以异步的方式通知到消费端，消费端及时更新调用的接口真实地址。
3. 服务端和消费端和zookeeper之间都是长连接，当服务端信息变更时，zookeepeer将及时收到并且通知消费端。
zookeeper如何实现分布式锁
分布式锁：保证不同服务器上的服务不能并发访问通过一段代码块。
zookeeper是目前默认实现分布式锁比较优雅的一种方式，实现的过程非常巧妙的利用了zookeeper的 “临时顺序节点”，其思想值得学习~
1. 获取锁
首先，在Zookeeper当中创建一个持久节点ParentLock。
接下来按照Client1/2/3的请求锁顺序来模拟整个过程：
（1）Client1想要获得锁时，需要再ParentLock上创建节点Lock1；
（2）Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
（3）Client2请求锁，按照步骤2创建临时顺序节点Lock2，发现自己的临时节点Lock2并不是第一个节点，此时Client2阻塞等待，并且监听前一个节点Lock1，即Lock1增加watch事件，watcher是Client2；
（4）Client3请求锁，和步骤3一样创建临时顺序节点Lock3，并且监听前一个节点Lock2；按照这样的步骤即生成了一个阻塞队列。
（5）此时，Client1执行完毕，删除节点Lock1，Client2监听到删除事件，执行步骤2，判断自己可以获得锁。
（6）Client2一执行完，Client3也会收到通知，和步骤5一样。
上述是正常执行的流程，假设某个客户端发生了崩溃宕机，那么zookeeper又是如何保证锁能正常释放呢？
==》此处正是利用了zookeeper临时节点的特性，假设Client1宕机失去和zookeeper的连接，Lock1节点会自动删除，此时监听Lock1的Client2就可以继续下面的操作，即步骤5.
kafka如何使用zookeeper
待补充~
推荐一篇介绍zookeeper很生动易懂的文章：程序员小灰—什么是zookeeper？