如何用Zookeeper實現(xiàn)分布式鎖?

在學(xué)習(xí)分布式鎖之前，需要首先了解一下Zookeeper的[臨時順序節(jié)點]。

什么是臨時順序節(jié)點？

讓我們來回顧一下Zookeeper節(jié)點的概念：

Zookeeper的數(shù)據(jù)存儲結(jié)構(gòu)就像一棵樹，這棵樹由節(jié)點組成，這種節(jié)點叫做Znode。

Znode分為四種類型

1.持久節(jié)點 （PERSISTENT）

默認(rèn)的節(jié)點類型。創(chuàng)建節(jié)點的客戶端與zookeeper斷開連接后，該節(jié)點依舊存在 。

2.持久節(jié)點順序節(jié)點（PERSISTENT_SEQUENTIAL）

所謂順序節(jié)點，就是在創(chuàng)建節(jié)點時，Zookeeper根據(jù)創(chuàng)建的時間順序給該節(jié)點名稱進行編號：

3.臨時節(jié)點（EPHEMERAL） 

和持久節(jié)點相反，當(dāng)創(chuàng)建節(jié)點的客戶端與zookeeper斷開連接后，臨時節(jié)點會被刪除。

4.臨時順序節(jié)點（EPHEMERAL_SEQUENTIAL） 

顧名思義，臨時順序節(jié)點結(jié)合和臨時節(jié)點和順序節(jié)點的特點：在創(chuàng)建節(jié)點時，Zookeeper根據(jù)創(chuàng)建的時間順序給該節(jié)點名稱進行編號；當(dāng)創(chuàng)建節(jié)點的客戶端與Zookeeper斷開連接后，臨時節(jié)點會被刪除。

那臨時順序節(jié)點和Zookeeper的分布式鎖有什么關(guān)系呢？

Zookeeper分布式鎖的原理

Zookeeper分布式鎖恰恰應(yīng)用了臨時順序節(jié)點。具體如何實現(xiàn)呢？讓我們來看一看詳細(xì)步驟：

獲取鎖

首先，在Zookeeper當(dāng)中創(chuàng)建一個持久節(jié)點ParentLock。當(dāng)?shù)谝粋€客戶端想要獲得鎖時，需要在ParentLock這個節(jié)點下面創(chuàng)建一個臨時順序節(jié)點 Lock1。

之后，Client1查找ParentLock下面所有的臨時順序節(jié)點并排序，判斷自己所創(chuàng)建的節(jié)點Lock1是不是順序最靠前的一個。如果是第一個節(jié)點，則成功獲得鎖。 

這時候，如果再有一個客戶端 Client2 前來獲取鎖，則在ParentLock下載再創(chuàng)建一個臨時順序節(jié)點Lock2。 

Client2查找ParentLock下面所有的臨時順序節(jié)點并排序，判斷自己所創(chuàng)建的節(jié)點Lock2是不是順序最靠前的一個，結(jié)果發(fā)現(xiàn)節(jié)點Lock2并不是最小的。

于是，Client2向排序僅比它靠前的節(jié)點Lock1注冊Watcher，用于監(jiān)聽Lock1節(jié)點是否存在。這意味著Client2搶鎖失敗，進入了等待狀態(tài)。 

這時候，如果又有一個客戶端Client3前來獲取鎖，則在ParentLock下載再創(chuàng)建一個臨時順序節(jié)點Lock3。 

Client3查找ParentLock下面所有的臨時順序節(jié)點并排序，判斷自己所創(chuàng)建的節(jié)點Lock3是不是順序最靠前的一個，結(jié)果同樣發(fā)現(xiàn)節(jié)點Lock3并不是最小的。

于是，Client3向排序僅比它靠前的節(jié)點Lock2注冊Watcher，用于監(jiān)聽Lock2節(jié)點是否存在。這意味著Client3同樣搶鎖失敗，進入了等待狀態(tài)。 

這樣一來，Client1得到了鎖，Client2監(jiān)聽了Lock1，Client3監(jiān)聽了Lock2。這恰恰形成了一個等待隊列，很像是Java當(dāng)中ReentrantLock所依賴的AQS（AbstractQueuedSynchronizer）。

獲得鎖的過程大致就是這樣，那么Zookeeper如何釋放鎖呢？

釋放鎖的過程很簡單，只需要釋放對應(yīng)的子節(jié)點就好。

釋放鎖

釋放鎖分為兩種情況：

1.任務(wù)完成，客戶端顯示釋放

當(dāng)任務(wù)完成時，Client1會顯示調(diào)用刪除節(jié)點Lock1的指令。

2.任務(wù)執(zhí)行過程中，客戶端崩潰

獲得鎖的Client1在任務(wù)執(zhí)行過程中，如果Duang的一聲崩潰，則會斷開與Zookeeper服務(wù)端的鏈接。根據(jù)臨時節(jié)點的特性，相關(guān)聯(lián)的節(jié)點Lock1會隨之自動刪除。 

由于Client2一直監(jiān)聽著Lock1的存在狀態(tài)，當(dāng)Lock1節(jié)點被刪除，Client2會立刻收到通知。這時候Client2會再次查詢ParentLock下面的所有節(jié)點，確認(rèn)自己創(chuàng)建的節(jié)點Lock2是不是目前最小的節(jié)點。如果是最小，則Client2順理成章獲得了鎖。 

同理，如果Client2也因為任務(wù)完成或者節(jié)點崩潰而刪除了節(jié)點Lock2，那么Client3就會接到通知。 

最終，Client3成功得到了鎖。 

使用Zookeeper實現(xiàn)分布式鎖的大致流程就是這樣。那么使用Zookeeper實現(xiàn)的分布式鎖和Redis實現(xiàn)的分布式鎖相比有什么優(yōu)勢和劣勢呢？

下面總結(jié)一下他們各自的優(yōu)劣

有人說Zookeeper實現(xiàn)的分布式鎖支持可重入，Redis實現(xiàn)的分布式鎖不支持可重入，這是錯誤的觀點。兩者都可以在客戶端實現(xiàn)可重入邏輯。

關(guān)于Zookeeper分布式鎖的內(nèi)容就介紹到這里啦。 

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論