分佈式利器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的介紹等，之後有空再分享，暫且保留下，哈哈）！