分布式鎖是什么？有什么作用？

分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式。如果不同的系統(tǒng)或是同一個(gè)系統(tǒng)的不同主機(jī)之間共享了一個(gè)或一組資源，那么訪問這些資源的時(shí)候，往往需要通過一些互斥手段來防止彼此之間的干擾，以保證一致性，在這種情況下，就需要使用分布式鎖了。

在平時(shí)的實(shí)際項(xiàng)目開發(fā)中，我們往往很少會(huì)去在意分布式鎖，而是依賴于關(guān)系型數(shù)據(jù)庫固有的排他性來實(shí)現(xiàn)不同進(jìn)程之間的互斥。這確實(shí)是一種非常簡便且被廣泛使用的分布式鎖實(shí)現(xiàn)方式。然而有一個(gè)不爭的事實(shí)是，目前絕大多數(shù)大型分布式系統(tǒng)的性能瓶頸都集中在數(shù)據(jù)庫操作上。因此，如果上層業(yè)務(wù)再給數(shù)據(jù)庫添加一些額外的鎖，例如行鎖、表鎖甚至是繁重的事務(wù)處理，那么就會(huì)讓數(shù)據(jù)庫更加不堪重負(fù)。

下面我們來看看使用ZooKeeper如何實(shí)現(xiàn)分布式鎖，這里主要講解排他鎖和共享鎖兩類分布式鎖。

排他鎖

排他鎖(Exclusive Locks，簡稱 X 鎖)，又稱為寫鎖或獨(dú)占鎖，是一種基本的鎖類型。如果事務(wù) T1對數(shù)據(jù)對象 O1加上了排他鎖，那么在整個(gè)加鎖期間，只允許事務(wù) T1對 O1進(jìn)行讀取和更新操作，其他任何事務(wù)都不能再對這個(gè)數(shù)據(jù)對象進(jìn)行任何類型的操作——直到T1釋放了排他鎖

從上面講解的排他鎖的基本概念中，我們可以看到，排他鎖的核心是如何保證當(dāng)前有且僅有一個(gè)事務(wù)獲得鎖，并且鎖被釋放后，所有正在等待獲取鎖的事務(wù)都能夠被通知到。

下面我們就來看看如何借助ZooKeeper實(shí)現(xiàn)排他鎖：

① 定義鎖

在通常的Java開發(fā)編程中，有兩種常見的方式可以用來定義鎖，分別是synchronized機(jī)制和JDK5提供的ReentrantLock。然而，在ZooKeeper中，沒有類似于這樣的API可以直接使用，而是通過 ZooKeeper 上的數(shù)據(jù)節(jié)點(diǎn)來表示一個(gè)鎖，例如/exclusive_lock/lock節(jié)點(diǎn)就可以被定義為一個(gè)鎖，如圖：

② 獲取鎖

在需要獲取排他鎖時(shí)，所有的客戶端都會(huì)試圖通過調(diào)用 create()接口，在/exclusive_lock節(jié)點(diǎn)下創(chuàng)建臨時(shí)子節(jié)點(diǎn)/exclusive_lock/lock。在前面，我們也介紹了，ZooKeeper 會(huì)保證在所有的客戶端中，最終只有一個(gè)客戶端能夠創(chuàng)建成功，那么就可以認(rèn)為該客戶端獲取了鎖。同時(shí)，所有沒有獲取到鎖的客戶端就需要到/exclusive_lock 節(jié)點(diǎn)上注冊一個(gè)子節(jié)點(diǎn)變更的Watcher監(jiān)聽，以便實(shí)時(shí)監(jiān)聽到lock節(jié)點(diǎn)的變更情況

③釋放鎖

在“定義鎖”部分，我們已經(jīng)提到，/exclusive_lock/lock 是一個(gè)臨時(shí)節(jié)點(diǎn)，因此在以下兩種情況下，都有可能釋放鎖。 · 當(dāng)前獲取鎖的客戶端機(jī)器發(fā)生宕機(jī)，那么ZooKeeper上的這個(gè)臨時(shí)節(jié)點(diǎn)就會(huì)被移除。 · 正常執(zhí)行完業(yè)務(wù)邏輯后，客戶端就會(huì)主動(dòng)將自己創(chuàng)建的臨時(shí)節(jié)點(diǎn)刪除。 無論在什么情況下移除了lock節(jié)點(diǎn)，ZooKeeper都會(huì)通知所有在/exclusive_lock節(jié)點(diǎn)上注冊了子節(jié)點(diǎn)變更Watcher監(jiān)聽的客戶端。這些客戶端在接收到通知后，再次重新發(fā)起分布式鎖獲取，即重復(fù)“獲取鎖”過程。整個(gè)排他鎖的獲取和釋放流程，如下圖：

共享鎖

共享鎖(Shared Locks，簡稱S鎖)，又稱為讀鎖，同樣是一種基本的鎖類型。

如果事務(wù)T1對數(shù)據(jù)對象O1加上了共享鎖，那么當(dāng)前事務(wù)只能對O1進(jìn)行讀取操作，其他事務(wù)也只能對這個(gè)數(shù)據(jù)對象加共享鎖——直到該數(shù)據(jù)對象上的所有共享鎖都被釋放。

共享鎖和排他鎖最根本的區(qū)別在于，加上排他鎖后，數(shù)據(jù)對象只對一個(gè)事務(wù)可見，而加上共享鎖后，數(shù)據(jù)對所有事務(wù)都可見。

下面我們就來看看如何借助ZooKeeper來實(shí)現(xiàn)共享鎖。

① 定義鎖
和排他鎖一樣，同樣是通過 ZooKeeper 上的數(shù)據(jù)節(jié)點(diǎn)來表示一個(gè)鎖，是一個(gè)類似于“/shared_lock/[Hostname]-請求類型-序號”的臨時(shí)順序節(jié)點(diǎn)，例如/shared_lock/host1-R-0000000001，那么，這個(gè)節(jié)點(diǎn)就代表了一個(gè)共享鎖，如圖所示：

② 獲取鎖

在需要獲取共享鎖時(shí)，所有客戶端都會(huì)到/shared_lock 這個(gè)節(jié)點(diǎn)下面創(chuàng)建一個(gè)臨時(shí)順序節(jié)點(diǎn)，如果當(dāng)前是讀請求，那么就創(chuàng)建例如/shared_lock/host1-R-0000000001的節(jié)點(diǎn);如果是寫請求，那么就創(chuàng)建例如/shared_lock/host2-W-0000000002的節(jié)點(diǎn)。

判斷讀寫順序

通過Zookeeper來確定分布式讀寫順序，大致分為四步

(1)創(chuàng)建完節(jié)點(diǎn)后，獲取/shared_lock節(jié)點(diǎn)下所有子節(jié)點(diǎn)，并對該節(jié)點(diǎn)變更注冊監(jiān)聽。

(2)確定自己的節(jié)點(diǎn)序號在所有子節(jié)點(diǎn)中的順序。

(3)對于讀請求：若沒有比自己序號小的子節(jié)點(diǎn)或所有比自己序號小的子節(jié)點(diǎn)都是讀請求，那么表明自己已經(jīng)成功獲取到共享鎖，同時(shí)開始執(zhí)行讀取邏輯，若有寫請求，則需要等待。對于寫請求：若自己不是序號最小的子節(jié)點(diǎn)，那么需要等待。

(4)接收到Watcher通知后，重復(fù)步驟1

③ 釋放鎖，其釋放鎖的流程與獨(dú)占鎖一致。


猜你喜歡：

HBase分布式數(shù)據(jù)庫的特點(diǎn)是什么?HBase簡介 

Java分布式事務(wù)處理視頻教程