Java ZooKeeper分布式鎖實(shí)現(xiàn)圖解

更新時(shí)間：2022年03月01日 14:37:41 作者：GuochaoHN

ZooKeeper是一個(gè)分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個(gè)開源的實(shí)現(xiàn)，是Hadoop和Hbase的重要組件。它是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護(hù)、域名服務(wù)、分布式同步、組服務(wù)等

什么是分布式鎖

1、在我們進(jìn)行單機(jī)應(yīng)用開發(fā)，涉及并發(fā)同步的時(shí)候，我們往往采用synchronized或者Lock的方式來解決多線程間的代碼同步問題，這時(shí)多線程的運(yùn)行都是在同一個(gè)JVM之下，沒有任何問題。

2、但當(dāng)我們的應(yīng)用是分布式集群工作的情況下，屬于多JVM下的工作環(huán)境（多臺(tái)機(jī)器），跨JVM之間已經(jīng)無法通過多線程的鎖解決同步問題。那么就需要一種更加高級(jí)的鎖機(jī)制，來處理種跨機(jī)器的進(jìn)程之間的數(shù)據(jù)同步問題——這就是分布式鎖。（多節(jié)點(diǎn)從分布式組件中獲取鎖）

例如以下實(shí)例：

各種搶票軟件客戶端通過zookeeper獲取鎖，最終只有一個(gè)客戶端可以獲得鎖并且先與12306服務(wù)器進(jìn)行數(shù)據(jù)通信，最終和12306數(shù)據(jù)庫(kù)服務(wù)器通行。通信完畢之后釋放鎖，其他客戶端獲取鎖之后執(zhí)行同樣的操作。（顯然前提是這幾個(gè)客戶端都通過負(fù)載均衡后均與節(jié)點(diǎn)集群中同一個(gè)服務(wù)器進(jìn)行通信）

3、其他分布式鎖

zookeeper分布式鎖原理

核心思想：當(dāng)客戶端要獲取鎖，則創(chuàng)建節(jié)點(diǎn)，使用完鎖，則刪除該節(jié)點(diǎn)。

1、客戶端獲取鎖時(shí)，在lock節(jié)點(diǎn)下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)。

2、然后獲取lock下面的所有子節(jié)點(diǎn)，客戶端獲取到所有的子節(jié)點(diǎn)之后，如果發(fā)現(xiàn)自己創(chuàng)建的子節(jié)點(diǎn)序號(hào)最小，那么就認(rèn)為該客戶端獲取到了鎖。使用完鎖后，將該節(jié)點(diǎn)刪除。

注意：

創(chuàng)建臨時(shí)節(jié)點(diǎn)的原因：

如果某個(gè)已經(jīng)獲取鎖了的節(jié)點(diǎn)發(fā)生宕機(jī)，如果是持久化節(jié)點(diǎn)，那么鎖就無法釋放。如果是臨時(shí)節(jié)點(diǎn)，在發(fā)生宕機(jī)后，連接斷開會(huì)自動(dòng)釋放鎖。

創(chuàng)建順序節(jié)點(diǎn)的原因：

將節(jié)點(diǎn)按順序編號(hào)，客戶端通過節(jié)點(diǎn)編號(hào)判斷自己是否是序號(hào)最小的節(jié)點(diǎn)，并且獲得鎖。

3、如果發(fā)現(xiàn)自己創(chuàng)建的節(jié)點(diǎn)并非lock所有子節(jié)點(diǎn)中最小的，說明自己還沒有獲取到鎖，此時(shí)客戶端需要找到比自己小的那個(gè)節(jié)點(diǎn)，同時(shí)對(duì)其注冊(cè)事件監(jiān)聽器，監(jiān)聽刪除事件。

4、如果發(fā)現(xiàn)比自己小的那個(gè)節(jié)點(diǎn)被刪除，則客戶端的 Watcher會(huì)收到相應(yīng)通知，此時(shí)再次判斷自己創(chuàng)建的節(jié)點(diǎn)是否是lock子節(jié)點(diǎn)中序號(hào)最小的，如果是則獲取到了鎖，如果不是則重復(fù)以上步驟繼續(xù)獲取到比自己小的一個(gè)節(jié)點(diǎn)并注冊(cè)監(jiān)聽。