Zookeeper 實作分布式鎖思路解析及Curator實戰

文章目錄

• • 前言
  • 需要考慮的細節
  • • • 如果出現異常，沒有删掉結點，進而這個鎖永遠無法釋放，怎麼辦？
      • 如果在Finally之前伺服器當機了怎麼辦？
      • 如果事件監聽機制會通知上輪取鎖失敗者，導緻羊群效應怎麼辦？
  • 基于Curator實作Zookeeper實戰

前言

Zookeeper實作分布式鎖的核心在于

獨占性

，即當有人建立過某結點，那麼再次建立的時候，就不可建立，我們可根據是否能成功建立來實作

加鎖

操作，而如何釋放鎖呢？走完流程删掉這個結點就可以了。

zk-用戶端連接配接zk實作，如果重複建立會提示‘

Node already exists: /lock

’，在并發情況下，隻有一個請求是可以建立成功的，其他的請求會通過

get -w

監聽該節點

[zk: localhost:2181(CONNECTED) 20] create /lock
Created /lock
[zk: localhost:2181(CONNECTED) 21] create /lock
Node already exists: /lock
           

整體思路比較簡單，但是要考慮很多細節。

需要考慮的細節

如果出現異常，沒有删掉結點，進而這個鎖永遠無法釋放，怎麼辦？

保證其釋放了就行，例如在Java中可以使用

try catch

中的

finally

去保證其進行删除結點的操作

如果在Finally之前伺服器當機了怎麼辦？

這樣Finally就失效了，此時我們想到了Zookeeper中的臨時結點，讓其自動釋放

如果事件監聽機制會通知上輪取鎖失敗者，導緻羊群效應怎麼辦？

可以使用臨時順序節點，為所有的擷取鎖請求建立臨時順序結點，這樣每個請求建立的臨時順序結點類似于lock0000001、lock0000002…這樣的形式，每次編号最小的擷取結點，且編号次小的會對編号最小的順序結點進行監聽，也就是2監聽1，3監聽2這種… ，2監聽到1釋放了，2就會拿鎖，這樣就避免了羊群效應。

基于Curator實作Zookeeper實戰

Curator是Zookeeper用戶端工具，也就是說我們可以在自己的系統中內建Curator，并借助它對Zookeeper進行操作。

引入Curator依賴

<dependency>
     <groupId>org.apache.curator</groupId>
     <artifactId>curator-recipes</artifactId>
     <version>4.3.0</version>
</dependency>