ZooKeeper分布式鎖詳解

分布式鎖機制

假設客戶端a搶先一步,對zk發起了加分布式鎖請求,這個加鎖請求用到了zk中的乙個特殊概念,叫做臨時順序節點

簡單來說,就是在my_lock這個鎖節點上建立了乙個順序節點,在zk內部自行維護的乙個節點順序號

舉個栗子:

第乙個客戶端來搞乙個順序節點,zk內部會給起個名字叫做:***-000001.然後第二個客戶端來搞乙個順序節點,zk可能會起個名字叫做:***-000002,最後乙個數字都是一次遞增的,從1開始遞增,zk會維護這個順序

接著,a建立完乙個順序節點,會檢視my_lock這個鎖節點下的所有子節點,並且這些子節點是按照序號排序的,會得到所有子節點序號的集合,然後進行判斷,判斷是否是排在第乙個,如果是的話,就可以加鎖了

a加完鎖後,b過來想要加鎖,b會幹一樣的事,現在my_lock下建立乙個臨時順序節點,名稱類似於asdfad-lock-000002

因為是第二個來建立順序節點的,所以zk內部會維護序號2,接著判斷是不是節點集合中的第乙個,判斷完得出不是,很遺憾加鎖失敗,加鎖失敗後,b不甘心,於是對上乙個順序節點加了乙個***,zk天然就可以實現對某個節點進行監聽(watch機制),也就是監聽a建立的那個順序節點,隨時等待a被刪除,然後上位加鎖

之後,a加鎖後,處理了一些邏輯後就釋放鎖了,也就是把自己建立的那個臨時節點刪除掉,b被zk通知重新嘗試去獲取鎖,也就是獲取my_lock節點下的子節點集合,此時只有b建立的唯一順序節點,上位加鎖!

有了多個cdf來爭搶鎖的情況

都是上來先直接建立乙個鎖節點下的乙個接乙個臨時節點,如果自己不是第乙個節點,那麼就對上乙個節點進行監聽,等待zk通知上位,此時相當於乙個派對機制

為什麼要使用臨時順序節點

如果某乙個客戶端建立臨時順序節點後,不小心宕機了,那麼zk也可以感知到,會自動刪除對應的臨時順序節點,相當於自動釋放鎖,或者自動取消自己的派對

// 定義鎖節點名稱
interprocessmutex lock =
interprocessmutex
(client,
"/locks/my_lock");
// 加鎖
lock.
acquire()
;// 業務邏輯**
pass
// 釋放鎖
lock.
release()
;