Zookeeper怎么實作分布式鎖？

作者：coolblog
https://segmentfault.com/a/1190000010895869

1. 背景

最近在學習 Zookeeper，在剛開始接觸 Zookeeper 的時候，完全不知道 Zookeeper 有什么用，且很多資料都是將 Zookeeper 描述成一個“類 Unix/Linux 檔案系統”的中間件，導致我很難將類 Unix/Linux 檔案系統的 Zookeeper 和分布式應用聯系在一起，

后來在粗讀了《ZooKeeper 分布式程序協同技術詳解》和《從Paxos到Zookeeper 分布式一致性原理與實踐》兩本書，并動手寫了一些 CURD demo 后，初步對 Zookeeper 有了一定的了解，

不過比較膚淺，為了進一步加深對 Zookeeper 的認識，我利用空閑時間撰寫了本篇文章對應的 demo – 基于 Zookeeper 的分布式鎖實作，通過撰寫這個分布式鎖 demo，使我對 Zookeeper 的 watcher 機制、Zookeeper 的用途等有了更進一步的認識，

不過我所撰寫的分布式鎖還是比較簡陋的，實作的也不夠優美，僅僅是個練習，僅供參考使用，好了，題外話就說到這里，接下來我們就來聊聊基于 Zookeeper 的分布式鎖實作，

2. 獨占鎖和讀寫鎖的實作

在本章，我將分別說明獨占鎖和讀寫鎖詳細的實作程序，并配以相應的流程圖幫助大家了解實作的程序，這里先說說獨占鎖的實作，Java中的鎖原理、鎖優化、CAS、AQS，這篇文章推薦大家看下，

2.1 獨占鎖的實作

獨占鎖又稱排它鎖，從字面意思上很容易理解他們的用途，即如果某個操作 O1 對訪問資源 R1 的程序加鎖，在操作 O1 結束對資源 R1 訪問前，其他操作不允許訪問資源 R1，以上算是對獨占鎖的簡單定義了，那么這段定義在 Zookeeper 的“類 Unix/Linux 檔案系統”的結構中是怎樣實作的呢？在鎖答案前，我們先看張圖：

圖1 獨占鎖的 Zookeeper 節點結構

如上圖，對于獨占鎖，我們可以將資源 R1 看做是 lock 節點，操作 O1 訪問資源 R1 看做創建 lock 節點，釋放資源 R1 看做洗掉 lock 節點，這樣我們就將獨占鎖的定義對應于具體的 Zookeeper 節點結構，通過創建 lock 節點獲取鎖，洗掉節點釋放鎖，詳細的程序如下：

1、多個客戶端競爭創建 lock 臨時節點 2、其中某個客戶端成功創建 lock 節點，其他客戶端對 lock 節點設定 watcher 3、持有鎖的客戶端洗掉 lock 節點或該客戶端崩潰，由 Zookeeper 洗掉 lock 節點 4、其他客戶端獲得 lock 節點被洗掉的通知 5、重復上述4個步驟，直至無客戶端在等待獲取鎖了

上面即獨占鎖具體的實作步驟，理解起來并不復雜，這里不再贅述，

圖2 獲取獨占鎖流程圖

2.2 讀寫鎖的實作

說完獨占鎖的實作，這節來說說讀寫鎖的實作，讀寫鎖包含一個讀鎖和寫鎖，操作 O1 對資源 R1 加讀鎖，且獲得了鎖，其他操作可同時對資源 R1 設定讀鎖，進行共享讀操作，

如果操作 O1 對資源 R1 加寫鎖，且獲得了鎖，其他操作再對資源 R1 設定不同型別的鎖都會被阻塞，總結來說，讀鎖具有共享性，而寫鎖具有排他性，那么在 Zookeeper 中，我們可以用怎樣的節點結構實作上面的操作呢？

圖3 讀寫鎖的 Zookeeper 節點結構

在 Zookeeper 中，由于讀寫鎖和獨占鎖的節點結構不同，讀寫鎖的客戶端不用再去競爭創建 lock 節點，所以在一開始，所有的客戶端都會創建自己的鎖節點，如果不出意外，所有的鎖節點都能被創建成功，此時鎖節點結構如圖3所示，之后，客戶端從 Zookeeper 端獲取 /share_lock 下所有的子節點，并判斷自己能否獲取鎖，如果客戶端創建的是讀鎖節點，獲取鎖的條件（滿足其中一個即可）如下：

1、自己創建的節點序號排在所有其他子節點前面 2、自己創建的節點前面無寫鎖節點

如果客戶端創建的是寫鎖節點，由于寫鎖具有排他性，所以獲取鎖的條件要簡單一些，只需確定自己創建的鎖節點是否排在其他子節點前面即可，

不同于獨占鎖，讀寫鎖的實作稍微復雜一下，讀寫鎖有兩種實作方式，各有異同，接下來就來說說這兩種實作方式，

讀寫鎖的第一種實作

第一種實作是對 /sharelock 節點設定 watcher，當 /sharelock 下的子節點被洗掉時，未獲取鎖的客戶端收到 /share_lock 子節點變動的通知，在收到通知后，客戶端重新判斷自己創建的子節點是否可以獲取鎖，如果失敗，再次等待通知，詳細流程如下：

1、所有客戶端創建自己的鎖節點 2、從 Zookeeper 端獲取 /sharelock 下所有的子節點，并對 /sharelock 節點設定 watcher 3、判斷自己創建的鎖節點是否可以獲取鎖，如果可以，持有鎖，否則繼續等待 4、持有鎖的客戶端洗掉自己的鎖節點，其他客戶端收到 /share_lock 子節點變動的通知 5、重復步驟2、3、4，直至無客戶端在等待獲取鎖了

上述步驟對于的流程圖如下：

圖4 獲取讀寫鎖實作1流程圖

上面獲取讀寫鎖流程并不復雜，但卻存在性能問題，以圖3所示鎖節點結構為例，第一個鎖節點 host1-W-0000000001 被移除后，Zookeeper 會將 /share_lock 子節點變動的通知分發給所有的客戶端，

但實際上，該子節點變動通知除了能影響 host2-R-0000000002 節點對應的客戶端外，分發給其他客戶端則是在做無用功，因為其他客戶端即使獲取了通知也無法獲取鎖，所以這里需要做一些優化，優化措施是讓客戶端只在自己關心的節點被洗掉時，再去獲取鎖，

讀寫鎖的第二種實作

在了解讀寫鎖第一種實作的弊端后，我們針對這一實作進行優化，這里客戶端不再對 /share_lock 節點進行監視，而只對自己關心的節點進行監視，還是以圖3的鎖節點結構進行舉例說明，host2-R-0000000002 對應的客戶端 C2 只需監視 host1-W-0000000001 節點是否被洗掉即可，

而 host3-W-0000000003 對應的客戶端 C3 只需監視 host2-R-0000000002 節點是否被洗掉即可，只有 host2-R-0000000002 節點被洗掉，客戶端 C3 才能獲取鎖，而 host1-W-0000000001 節點被洗掉時，產生的通知對于客戶端 C3 來說是無用的，即使客戶端 C3 回應了通知也沒法獲取鎖，Zookeeper 集群安裝配置，超詳細，速度收藏，推薦閱讀，

這里總結一下，不同客戶端關心的鎖節點是不同的，如果客戶端創建的是讀鎖節點，那么客戶端只需找出比讀鎖節點序號小的最后一個的寫鎖節點，并設定 watcher 即可，而如果是寫鎖節點，則更簡單，客戶端僅需對該節點的上一個節點設定 watcher 即可，詳細的流程如下：

1、所有客戶端創建自己的鎖節點 2、從 Zookeeper 端獲取 /share_lock 下所有的子節點 3、判斷自己創建的鎖節點是否可以獲取鎖，如果可以，持有鎖，否則對自己關心的鎖節點設定 watcher 4、持有鎖的客戶端洗掉自己的鎖節點，某個客戶端收到該節點被洗掉的通知，并獲取鎖 5、重復步驟4，直至無客戶端在等待獲取鎖了

上述步驟對于的流程圖如下：

圖5 獲取讀寫鎖實作2流程圖

3. 寫在最后

本文較為詳細的描述了基于 Zookeeper 分布式鎖的實作程序，并根據上面描述的兩種鎖原理實作了較為簡單的分布式鎖 demo，代碼放在了 github 上，需要的朋友自取，

因為這只是一個簡單的 demo，代碼實作的并不優美，僅供參考，最后，如果你覺得文章還不錯的話，歡迎點贊，如果有不妥的地方，也請提出來，我會虛心改之，

推薦去我的博客閱讀更多：

1.Java JVM、集合、多執行緒、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、后端、架構、阿里巴巴等大廠最新面試題

覺得不錯，別忘了點贊+轉發哦！

標籤：Java

上一篇：Java 合并、拆分Excel單元格（基于Spire.Cloud.SDK for Java）

下一篇：黑菜菌的JAVA學習筆記