分布式利器Zookeeper（三）

前言

《分布式利器Zookeeper（一）》

《分布式利器Zookeeper（二）:分布式锁》

本篇博客是分布式利器Zookeeper系列的最后一篇，涉及的话题是：Zookeeper分布式锁的代码实现、zkclient的使用、Curator框架介绍等。

Zookeeper分布式锁的代码实现

在上一篇博客中，从思路上已经分析了Zookeeper如何帮助咱们实现分布式锁，咱们直接来看代码：

[分布式客户端]

[获取分布式锁的方法lock:初始化ZK]

[获取分布式锁的方法lock:建立临时节点与判断最小路径]

[main测试]

[运行结果]

须要注意的是，即使监控到了比本身序号小的节点的删除Watcher，也须要再次确认下！

从结果上，看的很清楚，各个线程有序得到锁。

zkclient

zkclient是在zookeeper原生API基础上作了一点封装，简化了ZK的复杂性。

来看代码：

咱们观察下zkclient的使用，和之前基于zookeeper的原生API有哪些区别呢？

第一，原生API须要咱们利用CountDownLatch来确保ZK的初始化，如今zkclient帮助咱们屏蔽掉了这个细节

第二，原生API是不能够递归建立节点的，而zkclient能够帮助咱们递归建立不存在的父节点，还能够递归删除

第三，支持序列化操做，上面的代码你大概能够看出一些端倪，就是咱们从操做byte[]到操做String了。（事实上，在zkclient中你只须要实现ZkSerializer接口，就能够完成Object到byte[]的转换，虽然如此，可是实际开发中，利用JSON也挺好的！）

第四，还有最重要的一点就是，zkclient将对节点的操做和对节点的监控分离开了，在原生API中2者是耦合在一块儿的！从思想上来看，便于理解；从代码上来看，也简洁些（若是写在一块儿，头都大了）；更加方便的是，zkclient替咱们完成了重复watch的功能！

[watch订阅机制]

看到没有，是否是有点像MQ的订阅机制，很是好用！【可是也有点不太完美，子节点的数据变动为何没有监控呢，这有点不符合人性啊！还好有Curator...】

可是呢，咱们知道ZK是有不少应用场景的，好比实现分布式锁，zkclient并无替咱们进行封装，可是Curator框架能够帮助咱们作到！

Curator

为了更好实现Java操做Zookeeper服务器，后来出现Curator框架，功能很是强大，目前已是Apache的顶级项目，有不少丰富的特性，好比session超时重连，主从选举，分布式计数器，分布式锁等，很是有利于Zookeeper复杂场景下的开发。

POM文件：

增删改查：

Curator框架使用链式编程风格，易读性很强！

注意，不管是原生的API，仍是基于zkclient的API，都是提供的connectTimeout，而Curator提供了sessionTimeout，功能很强大。

不管是原生的API，仍是zkclient，都是支持异步回调的，可是Curator框架在支持异步回调的同时，增长了线程池供咱们优化！

[NodeCacheListener]

[PathChildrenCacheListener]

对于Curator而言，为了解决重复Watch的问题，它引入了一种全新的思想：Cache与ZK SERVER比对的机制。不管是原生的API，仍是基于ZKCLIENT的，其实它们解决思路都是重复注册！

思路决定出路！Curator经过事件驱动将客户端的Cache与ZK SERVER的数据比对，就天然而然的解决了重复WATCH的功能！为何Curator能成为Apache的顶级项目呢，我想大概就是由于它的不同凡响的设计思想！

在Curator中，有2种Listener，一个是监控节点的NodeCacheListener，一个是监控子节点的PathChildrenCacheListener。PathChildernCacheListener能够监控子节点的新增、修改、删除，很是好用！

好了，到这里，准备结束这个系列了（其实还有一些内容没有涉及，好比Curator的分布式锁、分布式barrier的介绍等，之后有空再分享，暂且保留下，哈哈）！