客户端
znode 可能含有数据，也可能没有。如果 znode 包含数据，那么数据存储为字节数组（byte array）。字节数组的具体格式特定于每个应用的实现，ZooKeeper 不直接 提供解析支持。不过一般情况下，以 UTF-8 或 ASCII 编码的字符串就已经够用了。
API 概述
ZooKeeper 的 API 可以抽象成以下方法：
-
create /path data
创建一个名为 /path 的 znode 节点，并包含数据 data
-
delete /path
删除名为 /path 的 znode
-
exists /path
检查是否存在名为 /path 的节点
-
setData /path data
设置名为 /path 节点数据为 data
-
getData /path
返回名为 /path 节点的所有子节点列表
需要注意的是，ZooKepper 并不允许局部写入或读取 znode 节点的数据。当设置一个 znode 节点的数据或读取时，znode 节点的内容会被整个替换或者全部读取。
zkCli.sh
ZooKeeper 安装包提供了客户端工具 zkCli.sh（zkCli.cmd）方便我们学习实验 API 接口，该工具位于 bin 目录下，启动命令格式为：
bin/zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183
后面一段“127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183”是 ZooKeeper 集群的 IP 和端口组成的字符串，客户端会以随机顺序连接到服务器中。连接上集群后，如下图显示：
其中 0x15a0d2841340001 是本次 session 的 id。
这儿简单的演示临时节点和监视点特性：
- 同时开两个 zkCli 分别为 A，B；
A 连接至 127.0.0.1:2181
B 连接至 127.0.0.1:2182。
- A 创建临时节点：create -e /temp_a "temp a znode"
- B 查看节点数据并设置监控点：get /temp_a true
- A 关闭模拟客户端崩溃。
A 创建的临时节点被删除
因为监视点的设置，B 收到 /temp_a 删除通知
开源客户端库
zkCli 只适合学习和试验 ZooKeeper 集群，如果我们需要利用 ZooKeeper 实际开发分布式协同任务的系统时，可以使用 ZooKeeper 自带的客户端库。不过这些 jar 包只提供基本的阻塞和非阻塞 API 接口，需要开发人员自己实现类似会话超时重连，重复设置监视点等功能。除了 ZooKeeper 自带的客户端包，还可以使用以下客户端模块。
- zkClient
zkClient 是 Github 上一个开源的 ZooKeeper 客户端，是由 Datameer的工程师 Stefan Groschupf 和 Peter Voss 一起开发的。zkClient 在原生 API 上进行封装，是一个更简单易用的 ZooKeeper 客户端。同时，zkClient 在内部实现了诸如 session 超时重练，Watcher 反复注册等功能，使这些繁琐复杂的功能对开发人员透明。
地址：https://github.com/sgroschupf/zkclient
- Curator
Curator 是 Netflix 公司开源的一套 ZooKeeper 客户端框架，和 zkClient 一样，Curator 解决了很多 ZooKeeper 客户端非常底层的细节开发工作，目前已成为 Apache 的顶级项目，是全世界范围内使用最广泛的 ZooKeeper 客户端之一。
除了封装底层细节，使之对开发透明，Curator 还提供了一套易用性和可读性更强的 Fluent 风格的 API 框架。
除此之外，Curator 还提供饿了 ZooKeeper 各种应用场景的抽象封装（Recipe），如共享锁服务，Master 选举机制和分布式计数器等。
地址：http://curator.apache.org/curator-recipes/index.html
典型应用
需要再次说明 ZooKeeper 是保证分布式数据一致性和任务协调的框架，它并不会直接实现具体的分布式锁，Master 选举等分布式功能，而是提供一些简单易用的 API 接口，具体的功能实现需要开发者根据情况自行实现。另一方面，ZooKeeper 同时也是一个典型的发布／订阅模式的分布式数据管理与协调方案，配合监视点事件通知机制，可以非常方便地构建一些列分布式应用中都会涉及的核心功能：
- 数据发布/订阅
- 负载均衡
- 命名服务
- 分布式协调/通知
- 集群管理
- Master 选举
- 分布式锁
- 分布式队列
下面简单介绍下分布式锁的实现思路。
分布式锁
假设一个应用由 n 个进程组成，分别为 p1, p2 .... pn，这些进程尝试获取一个锁从而进入临界区进行操作。这儿我们可以使用 ZooKeeper 的 znode 来代表一个锁，如“/lock”。
- 所有进程同时尝试创建这个 znode，由 ZooKeeper 来保证顺序性。
- 如果某进程成功创建了 “/lock”，假设为 p4，则代表 p4 抢占到了该分布式锁，p4 可以执行临界区代码，其他进程则会因为 znode 存在而创建失败。
- 它们可以在 “/lock”节点上创建监视器后等待 znode 删除通知，如果删除通知到来，则重复 1 抢占锁。
- p4 释放锁时，删除 “/lock”节点即可，需要注意，因为 p4 很可能执行临界区代码时崩溃，所以“/lock”节点应该临时节点，如果 p4 崩溃，则该节点自行删除。
羊群效应
上述分布式锁的实现简单易用，但是却会造成“羊群效应”。想象一下，如果有 1000 个客户端同时调用 exists 监视“/lock”节点变化。那么当这个 znode 创建或删除时就会发送 1000 个通知，这个被监视的 znode 的一个变化会产生一个尖峰的通知，该尖峰时刻提交的操作可能会产生很高的延迟。
为了防止羊群效应的产生，利用有序节点，分布式锁不妨换一种实现方式：
- 系统已经存在“/lock”节点，争抢锁的进程在该节点下创建临时有序子节点，形如：/lock/192.168.1.200:2222-00000001;
- 进程获取 /lock 下子节点列表，判断自己的节点位置:
- 如果自己的节点序号最小，则表示获得锁，执行临界区代码;
- 如果不是，则在自己序号前一个子节点增加监视点 Watcher，等待删除通知。
- 获取锁的进程，执行外临界代码，删除自己的子节点，表示释放锁；
- 下一个子节点序号的进程获取删除通知，重复动作 2。
这种实现方式下，进程只监测排在它前面进程的节点，而不是 所有进程都监测 /lock 节点，避免了“羊群效应”。结构如下图所示：
ZooKeeper 和 Dubbo
Dubbo 是阿里巴巴开源（好像开源版本已经停止更新）的由 Java 语言编写的分布式服务框架，致力于提供高性能和透明化的远程服务调用方案和 SOA 服务治理方案。
目前 Github 地址：https://github.com/alibaba/dubbo
主页地址： http://dubbo.io/
Dubbo 基于 ZooKeeper 实现服务注册中心。注册中心是 RPC 框架最核心的模块之一，用于服务的注册和订阅。在 Dubbo 的实现中，对注册中心模块进行抽象封装，因此可以基于其提供的外部接口实现各种不同类型的注册中心，例如数据库，Redis 等。
在 Dubbo 注册中心的整体架构中，ZooKeeper 上服务的节点设计如下图所示：
- /dubbo 这是 Dubbo 在 ZooKeeper 上创建的根节点
- /dubbo/com.foo.BarService 是服务节点，代表了 Dubbo 的一个服务
- /dubbo/com.foo.BarService/providers 这是服务提供者的根节点，其子节点代表每一个服务真正提供者
- /dubbo/com.foo.BarService/consumers 这是服务消费者的根节点，其子节点代表每一个服务的真正消费者
流程说明：
- 服务提供者（Provider）启动
- 向 /dubbo/com.foo.BarService/providers 目录下写入自己的URL地址。
- 服务消费者（Consumer）启动时
- 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者URL地址。
- 并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的URL地址。
- 监控中心（Monitor）启动时
- 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者URL地址。
需要注意的是，所有提供者和消费者在 ZooKeeper 上创建的节点都是临时节点，利用临时节点生命周期和会话绑定的特性，一旦机器发生故障导致服务提供者无法对外提供服务，该临时节点就会自动从 ZooKeeper 上删除。
内容来源
从 Paxos 到 ZooKeeper 分布式一致性原理与实践
ZooKeeper 分布式过程协同技术详解
https://github.com/alibaba/dubbo
http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-Zookeeper%E6%B3%A8%E5%86%8C%E4%B8%AD%E5%BF%83
