前言
本篇博客是分布式利器Zookeeper系列的最后一篇，涉及的話題是：Zookeeper分布式鎖的代碼實現(xiàn)、zkclient的使用、Curator框架介紹等。
Zookeeper分布式鎖的代碼實現(xiàn)
在上一篇博客中，從思路上已經(jīng)分析了Zookeeper如何幫助我們實現(xiàn)分布式鎖，我們直接來看代碼：
需要注意的是，即便監(jiān)控到了比自己序號小的節(jié)點的刪除Watcher，也需要再次確認下！
從結(jié)果上，看的很清楚，各個線程有序獲得鎖。
zkclient
zkclient是在zookeeper原生API基礎上做了一點封裝，簡化了ZK的復雜性。
來看代碼：
我們觀察下zkclient的使用，和以前基于zookeeper的原生API有哪些區(qū)別呢？
第一，原生API需要我們利用CountDownLatch來確保ZK的初始化，現(xiàn)在zkclient幫助我們屏蔽掉了這個細節(jié)
第二，原生API是不可以遞歸創(chuàng)建節(jié)點的，而zkclient可以幫助我們遞歸創(chuàng)建不存在的父節(jié)點，還可以遞歸刪除
第三，支持序列化操作，上面的代碼你大概可以看出一些端倪，就是我們從操作byte[]到操作String了。（事實上，在zkclient中你只需要實現(xiàn)ZkSerializer接口，就可以完成Object到byte[]的轉(zhuǎn)換，雖然如此，但是實際開發(fā)中，利用JSON也挺好的?。?/b>
第四，還有最重要的一點就是，zkclient將對節(jié)點的操作和對節(jié)點的監(jiān)控分離開了，在原生API中2者是耦合在一起的！從思想上來看，便于理解；從代碼上來看，也簡潔些（如果寫在一起，頭都大了）；更加方便的是，zkclient替我們完成了重復watch的功能！
看到?jīng)]有，是不是有點像MQ的訂閱機制，非常好用！【但是也有點不太完美，子節(jié)點的數(shù)據(jù)變更為什么沒有監(jiān)控呢，這有點不符合人性??！還好有Curator...】
但是呢，我們知道ZK是有很多應用場景的，比如實現(xiàn)分布式鎖，zkclient并沒有替我們進行封裝，但是Curator框架可以幫助我們做到！
Curator
為了更好實現(xiàn)Java操作Zookeeper服務器，后來出現(xiàn)Curator框架，功能非常強大，目前已經(jīng)是Apache的頂級項目，有很多豐富的特性，比如session超時重連，主從選舉，分布式計數(shù)器，分布式鎖等，非常有利于Zookeeper復雜場景下的開發(fā)。
POM文件：
增刪改查：
Curator框架使用鏈式編程風格，易讀性很強！
注意，不論是原生的API，還是基于zkclient的API，都是提供的connectTimeout，而Curator提供了sessionTimeout，功能很強大。
無論是原生的API，還是zkclient，都是支持異步回調(diào)的，但是Curator框架在支持異步回調(diào)的同時，增加了線程池供我們優(yōu)化！
對于Curator而言，為了解決重復Watch的問題，它引入了一種全新的思想：Cache與ZK SERVER比對的機制。不論是原生的API，還是基于ZKCLIENT的，其實它們解決思路都是重復注冊！
思路決定出路！Curator通過事件驅(qū)動將客戶端的Cache與ZK SERVER的數(shù)據(jù)比對，就自然而然的解決了重復WATCH的功能！為什么Curator能成為Apache的頂級項目呢，我想大概就是因為它的與眾不同的設計思想！
在Curator中，有2種Listener，一個是監(jiān)控節(jié)點的NodeCacheListener，一個是監(jiān)控子節(jié)點的PathChildrenCacheListener。PathChildernCacheListener可以監(jiān)控子節(jié)點的新增、修改、刪除，非常好用！
好了，到這里，準備結(jié)束這個系列了（其實還有一些內(nèi)容沒有涉及，比如Curator的分布式鎖、分布式barrier的介紹等，以后有空再分享，暫且保留下，哈哈）！
