在上一篇漫畫中,小灰介紹了如何使用redis實(shí)現(xiàn)分布式鎖。
那么,如何用Zookeeper來(lái)實(shí)現(xiàn)分布式鎖呢?
這一次我們會(huì)為大家詳細(xì)講述。
喜歡的點(diǎn)點(diǎn)關(guān)注,點(diǎn)點(diǎn)贊。
對(duì)Java技術(shù),架構(gòu)技術(shù)感興趣的朋友,歡迎加QQ群728821520,一起學(xué)習(xí),相互討論
什么是臨時(shí)順序節(jié)點(diǎn)?
讓我們來(lái)回顧一下Zookeeper節(jié)點(diǎn)的概念:
Zookeeper的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)就像一棵樹(shù),這棵樹(shù)由節(jié)點(diǎn)組成,這種節(jié)點(diǎn)叫做Znode。
Znode分為四種類型:
1.持久節(jié)點(diǎn) (PERSISTENT)
默認(rèn)的節(jié)點(diǎn)類型。創(chuàng)建節(jié)點(diǎn)的客戶端與zookeeper斷開(kāi)連接后,該節(jié)點(diǎn)依舊存在 。
2.持久節(jié)點(diǎn)順序節(jié)點(diǎn)(PERSISTENT_SEQUENTIAL)
所謂順序節(jié)點(diǎn),就是在創(chuàng)建節(jié)點(diǎn)時(shí),Zookeeper根據(jù)創(chuàng)建的時(shí)間順序給該節(jié)點(diǎn)名稱進(jìn)行編號(hào):
3.臨時(shí)節(jié)點(diǎn)(EPHEMERAL)
和持久節(jié)點(diǎn)相反,當(dāng)創(chuàng)建節(jié)點(diǎn)的客戶端與zookeeper斷開(kāi)連接后,臨時(shí)節(jié)點(diǎn)會(huì)被刪除:
4.臨時(shí)順序節(jié)點(diǎn)(EPHEMERAL_SEQUENTIAL)
顧名思義,臨時(shí)順序節(jié)點(diǎn)結(jié)合和臨時(shí)節(jié)點(diǎn)和順序節(jié)點(diǎn)的特點(diǎn):在創(chuàng)建節(jié)點(diǎn)時(shí),Zookeeper根據(jù)創(chuàng)建的時(shí)間順序給該節(jié)點(diǎn)名稱進(jìn)行編號(hào);當(dāng)創(chuàng)建節(jié)點(diǎn)的客戶端與zookeeper斷開(kāi)連接后,臨時(shí)節(jié)點(diǎn)會(huì)被刪除。
Zookeeper分布式鎖的原理
Zookeeper分布式鎖恰恰應(yīng)用了臨時(shí)順序節(jié)點(diǎn)。具體如何實(shí)現(xiàn)呢?讓我們來(lái)看一看詳細(xì)步驟:
獲取鎖
首先,在Zookeeper當(dāng)中創(chuàng)建一個(gè)持久節(jié)點(diǎn)ParentLock。當(dāng)?shù)谝粋€(gè)客戶端想要獲得鎖時(shí),需要在ParentLock這個(gè)節(jié)點(diǎn)下面創(chuàng)建一個(gè)臨時(shí)順序節(jié)點(diǎn)?Lock1。
之后,Client1查找ParentLock下面所有的臨時(shí)順序節(jié)點(diǎn)并排序,判斷自己所創(chuàng)建的節(jié)點(diǎn)Lock1是不是順序最靠前的一個(gè)。如果是第一個(gè)節(jié)點(diǎn),則成功獲得鎖。
這時(shí)候,如果再有一個(gè)客戶端 Client2 前來(lái)獲取鎖,則在ParentLock下載再創(chuàng)建一個(gè)臨時(shí)順序節(jié)點(diǎn)Lock2。
Client2查找ParentLock下面所有的臨時(shí)順序節(jié)點(diǎn)并排序,判斷自己所創(chuàng)建的節(jié)點(diǎn)Lock2是不是順序最靠前的一個(gè),結(jié)果發(fā)現(xiàn)節(jié)點(diǎn)Lock2并不是最小的。
于是,Client2向排序僅比它靠前的節(jié)點(diǎn)Lock1注冊(cè)Watcher,用于監(jiān)聽(tīng)Lock1節(jié)點(diǎn)是否存在。這意味著Client2搶鎖失敗,進(jìn)入了等待狀態(tài)。
這時(shí)候,如果又有一個(gè)客戶端Client3前來(lái)獲取鎖,則在ParentLock下載再創(chuàng)建一個(gè)臨時(shí)順序節(jié)點(diǎn)Lock3。
Client3查找ParentLock下面所有的臨時(shí)順序節(jié)點(diǎn)并排序,判斷自己所創(chuàng)建的節(jié)點(diǎn)Lock3是不是順序最靠前的一個(gè),結(jié)果同樣發(fā)現(xiàn)節(jié)點(diǎn)Lock3并不是最小的。
于是,Client3向排序僅比它靠前的節(jié)點(diǎn)Lock2注冊(cè)Watcher,用于監(jiān)聽(tīng)Lock2節(jié)點(diǎn)是否存在。這意味著Client3同樣搶鎖失敗,進(jìn)入了等待狀態(tài)。
這樣一來(lái),Client1得到了鎖,Client2監(jiān)聽(tīng)了Lock1,Client3監(jiān)聽(tīng)了Lock2。這恰恰形成了一個(gè)等待隊(duì)列,很像是Java當(dāng)中ReentrantLock所依賴的AQS(AbstractQueuedSynchronizer)。
釋放鎖
釋放鎖分為兩種情況:
1.任務(wù)完成,客戶端顯示釋放
當(dāng)任務(wù)完成時(shí),Client1會(huì)顯示調(diào)用刪除節(jié)點(diǎn)Lock1的指令。
2.任務(wù)執(zhí)行過(guò)程中,客戶端崩潰
獲得鎖的Client1在任務(wù)執(zhí)行過(guò)程中,如果Duang的一聲崩潰,則會(huì)斷開(kāi)與Zookeeper服務(wù)端的鏈接。根據(jù)臨時(shí)節(jié)點(diǎn)的特性,相關(guān)聯(lián)的節(jié)點(diǎn)Lock1會(huì)隨之自動(dòng)刪除。
由于Client2一直監(jiān)聽(tīng)著Lock1的存在狀態(tài),當(dāng)Lock1節(jié)點(diǎn)被刪除,Client2會(huì)立刻收到通知。這時(shí)候Client2會(huì)再次查詢ParentLock下面的所有節(jié)點(diǎn),確認(rèn)自己創(chuàng)建的節(jié)點(diǎn)Lock2是不是目前最小的節(jié)點(diǎn)。如果是最小,則Client2順理成章獲得了鎖。
同理,如果Client2也因?yàn)槿蝿?wù)完成或者節(jié)點(diǎn)崩潰而刪除了節(jié)點(diǎn)Lock2,那么Client3就會(huì)接到通知。
最終,Client3成功得到了鎖。
Zookeeper和Redis分布式鎖的比較
下面的表格總結(jié)了Zookeeper和Redis分布式鎖的優(yōu)缺點(diǎn):
有人說(shuō)Zookeeper實(shí)現(xiàn)的分布式鎖支持可重入,Redis實(shí)現(xiàn)的分布式鎖不支持可重入,這是錯(cuò)誤的觀點(diǎn)。兩者都可以在客戶端實(shí)現(xiàn)可重入邏輯。
在Apache的開(kāi)源框架?Apache Curator?中,包含了對(duì)Zookeeper分布式鎖的實(shí)現(xiàn),有興趣的小伙伴可以看看源碼:
https://github.com/apache/curator/