如果发生session close、authFail和invalid，那么所有类型的wather都会被触发 zkClient除了做了一些便捷包装之外，对watcher使用做了一点增强。比如subscribeChildChanges实际上是通过exists和getChildren关注了两个事件。这样当create("/path")时，对应path上通过getChildren注册的listener也会被调用。另外subscribeDataChanges实际上只是通过exists注册了事件。因为从上表可以看到，对于一个更新，通过exists和getData注册的watcher要么都会触发，要么都不会触发。 zkClient地址：[https://github.com/sgroschupf/zkclient](https://github.com/sgroschupf/zkclient) Maven工程中使用zkClient需要加的依赖：
<dependency> <groupId>zkclient</groupId> <artifactId>zkclient</artifactId> <version>0.1</version> </dependency>
二、 menagerie
menagerie基于Zookeeper实现了java.util.concurrent包的一个分布式版本。这个封装是更大粒度上对各种分布式一致性使用场景的抽象。其中最基础和常用的是一个分布式锁的实现：
org.menagerie.locks.ReentrantZkLock，通过ZooKeeper的全局有序的特性和EPHEMERAL_SEQUENTIAL类型znode的支持，实现了分布式锁。具体做法是：不同的client上每个试图获得锁的线程，都在相同的basepath下面创建一个EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要创建的是临时znode，创建连接断开时会自动删除； SEQUENTIAL表示要自动在传入的path后面缀上一个自增的全局唯一后缀,作为最终的path。因此对不同的请求ZK会生成不同的后缀，并分别返回带了各自后缀的path给各个请求。因为ZK全局有序的特性，不管client请求怎样先后到达，在ZKServer端都会最终排好一个顺序，因此自增后缀最小的那个子节点，就对应第一个到达ZK的有效请求。然后client读取basepath下的所有子节点和ZK返回给自己的path进行比较，当发现自己创建的sequential node的后缀序号排在第一个时，就认为自己获得了锁；否则的话，就认为自己没有获得锁。这时肯定是有其他并发的并且是没有断开的client/线程先创建了node。
基于分布式锁，还实现了其他业务场景，比如leader选举：
[url=] [/url]
public static void leaderElectionTest() {ZkSessionManager zksm = new DefaultZkSessionManager(“ZK-host-ip:2181”, 5000);LeaderElector elector = new ZkLeaderElector(“/leaderElectionTest”, zksm, Ids.OPEN_ACL_UNSAFE);if (elector.nominateSelfForLeader()) {System.out.println(“Try to become the leader success!”);}}[url=][/url]
java.util.concurrent包下面的其他接口实现，也主要是基于ReentrantZkLock的，比如ZkHashMap实现了ConcurrentMap。具体请参见menagerie的API文档
menagerie地址：
Maven工程中使用menagerie需要加的依赖：
<dependency> <groupId>org.menagerie</groupId> <artifactId>menagerie</artifactId> <version>1.1-SNAPSHOT</version> </dependency> |
