前面我們剖析了Redisson的原始碼，主要分析了Redisson實現Redis分散式鎖的15問，理清了Redisson是如何實現的分散式鎖和一些其它的特性。這篇文章就來接著剖析Zookeeper分散式鎖的實現框架Curator的原始碼，看看Curator是如何實現Zookeeper分散式鎖的，以及它提供的哪些其它的特性。
Curator框架是封裝對於zk操作的api，其中就包括了對分散式鎖的實現，當然Curator框架也包括其它的功能，分散式鎖只是Curator的一部分功能。
本文的目錄跟Redisson文章的目錄比較相似，主要是為了方便大家對比redis和zk分散式鎖的實現。如需要Redisson原始碼剖析的文章，請關注微信公眾號 三友的java日記，回覆 Redisson 即可。
一、ZK分散式鎖實現原理
實現Zookeeper分散式鎖，主要是基於Zookeeper的臨時順序節點來實現的。
當客戶端來加鎖的時候，會先在加鎖的節點下建立一個子節點，這個節點就有一個序號，類似 lock-000001 ，建立成功之後會返回給客戶端所建立的節點，然後客戶端會去獲取這個加鎖節點下的所有客戶端建立的子節點，當然也包括自己建立的子節點。拿到所有節點之後，給這些節點進行排序，然後判斷自己建立的節點在這些節點中是否排在第一位，如果是的話，那麼就代表當前客戶端就算加鎖成功了，如果不是的話，那麼就代表當前客戶端加鎖失敗。
加鎖失敗的節點並不會不停地迴圈去嘗試加鎖，而是在自己建立節點的前一個節點上加一個監聽器，然後就進行等待。當前面一個節點釋放了鎖，就會反過來通知等待的客戶端，然後客戶端就加鎖成功了。
為什麼需要在前一個節點加個監聽器？
假設有很多客戶端來加鎖，然後加鎖失敗的都對前一個節點加一個監聽。那麼一旦第一個加鎖成功的客戶端執行緒釋放了鎖，那麼被喚醒的就是第二個客戶端執行緒，第二個客戶端執行緒就會加鎖成功，執行完任務之後就釋放了鎖，那麼就會喚醒第三個客戶端執行緒，第三個客戶端執行緒加鎖成功，執行完任務之後就釋放了鎖，喚醒第四個客戶端執行緒，以此類推，所以每次釋放鎖都會喚醒下一個節點，這樣每個加鎖的執行緒都會加鎖成功，所以監聽器的作用是喚醒加鎖失敗阻塞等待的客戶端。
二、為什麼使用臨時順序節點
下面介紹一下臨時節點、持久化節點、順序節點的特性。
1）臨時節點
臨時節點，指的是節點建立後，如果建立節點的客戶端和 Zookeeper 服務端的會話失效(例如斷開連線)，那麼節點就會被刪除。
2）持久化節點
持久化節點指的是節點建立後，即使建立節點的客戶端和 Zookeeper 服務端的會話失效(例如斷開連線)，節點也不會被刪除，只有客戶端主動發起刪除節點的請求，節點才會被刪除。
3）有序節點
有序節點，這種節點在建立時會有一個序號，這個序號是自增的。有序節點既可以是有序臨時節點，也可以是有序持久化節點。
從上面節點的特性可以知道，臨時節點相比持久節點，最主要的是對會話失效的情況處理不一樣，如果使用臨時節點的話，如果客戶端發生異常的話，沒有來得及主動釋放鎖，就能避免鎖無法釋放導致死鎖的情況。因為一旦客戶端異常，那麼客戶端和服務端之間的會話就會失效，然後臨時節點就會被刪除，這樣就釋放了鎖；而持久化節點在由於會話失效無法被刪除，那麼就不會去釋放鎖，這樣就會產生死鎖的問題。
從這裡可以看出redis和zk防止死鎖的實現是不同的，redis是通過過期時間來防止死鎖，而zk是通過臨時節點來防止死鎖的。
為什麼使用順序節點？其實為了防止羊群效應。如果沒有使用順序節點，假設很多客戶端都會去加鎖，那麼加鎖就會都失敗，都會對加鎖的節點加個監聽器，那麼一旦鎖釋放，那麼所有的加鎖客戶端都會被喚醒來加鎖，那麼一瞬間就會造成很多加鎖的請求，增加服務端的壓力。
所以綜上，臨時順序節點是個比較好的選擇。
三、加鎖的邏輯是如何實現的
前面關於ZK分散式鎖實現原理已經說過了，接下來就來看一下程式碼的實現。
加鎖的使用方法如下，接下來幾節會著重講解這段程式碼背後的邏輯
acquire方法的實現
acquire方法會去呼叫internalLock方法，傳入超時時間 -1 和單位 null，也就代表瞭如果加鎖不成功會一直阻塞直至加鎖成功，不會超時。
internalLock方法會先去獲取當前執行緒，然後從threadData中獲取當前執行緒對應的LockData，這裡面封裝了加鎖的資訊和次數，是實現可重入鎖的關鍵，當然第一次加鎖這裡肯定是沒有的，會繼續下走 internals.attemptLock 加鎖。
attemptLock方法
先通過driver的createsTheLock去建立節點。
從這裡看出，建立的節點型別是臨時順序節點，建立成功之後，就會返回當前建立的節點。
節點建立成功之後，會呼叫internalLockLoop方法來加鎖。
通過getSortedChildren方法獲取排好序的子節點，然後獲取當前的節點名稱，再通過 driver.getsTheLock判斷當前的節點有沒有加鎖成功，返回一個PredicateResults判斷的結果，這裡面存的就是否加鎖成功的資訊。
第一次加鎖，那麼到這裡就加鎖成功了。之後就會封裝一個LockData物件，放入threadData 的map中。
加鎖的流程如下圖：
四、如何實現可重入加鎖
上文加鎖的時候提到了，當第一次加鎖成功之後，會往threadData放入該加鎖的執行緒對應的LockData。
LockData主要封裝了當前執行緒、加鎖的次數、加鎖的節點。
此時如果第二次來加鎖，那麼就會從threadData中獲取到加鎖的資訊，然後將加鎖次數加1，就代表了加鎖成功，然後直接返回。
所以可重入加鎖的實現很簡單，就是在客戶端中判斷有沒有加過鎖，加過的話就將加鎖次數累加1，壓根就跟服務端沒有互動。
注意Redisson可重入加鎖的實現跟的Curator是不一樣的，Redisson的加鎖次數是存在Redis的服務端的，而Curator是存在客戶端的。
五、加鎖失敗之後如何實現阻塞等待加鎖
前面加鎖的邏輯主要是說了加鎖成功的情況，這裡就來說一下加鎖失敗的情況。
繼續來看internalLockLoop方法。
前面說過，判斷有沒有加鎖成功，會返回一個PredicateResults，這裡麵包含了有沒有加鎖成功的資訊，同時如果沒有加鎖成功，就會返回需要監聽的節點，也就是當前建立的節點的前一個節點。
所以沒有加鎖成功，就會走else的邏輯，對上一個節點加一個監聽器 watcher
然後就會呼叫 wait 方法，進行等待。
當前一個節點被刪除了，也就是釋放了鎖，那麼就會回撥這個監聽器watcher的方法。
所以，這個watcher的作用就是呼叫notifyAll方法喚醒呼叫wait方法的執行緒，這樣執行緒就會繼續嘗試加鎖，因為是在一個while的迴圈中。
六、如何實現阻塞等待一定時間還未加鎖成功就放棄加鎖
可通過下面這個方法來實現實現阻塞等待一定時間還未加鎖成功就放棄加鎖。
boolean acquire(long time, TimeUnit unit) throws Exception
這個方法相比不指定等待時間的方法最主要的區別就是加鎖失敗之後，呼叫的阻塞的方法不一樣。當不指定超時時間就會呼叫wait()方法，不會傳入等待時間，不被喚醒就會一直阻塞；指定超時時間的時候，就會呼叫wait(long timeout)指定等待的時間，這樣如果等待時間一到，執行緒就會醒過來，然後再次嘗試加鎖，一旦加鎖失敗，就會放棄加鎖。
七、如何主動釋放鎖和避免其它執行緒釋放鎖
釋放鎖release方法
釋放鎖其實很簡單，就是拿出當前執行緒對應的LockData，如果沒有，就說明當前執行緒沒有加過鎖，就會丟擲異常，所以Curator就是通過這個判斷來防止其它執行緒釋放了自己執行緒加的鎖。
如果加鎖了，那麼LockData就不會為null，然後將加鎖次數遞減1，得到newLockCount，代表了剩下的加鎖次數。
-
如果newLockCount > 0，說明鎖沒釋放完，有可重入加鎖，然後什麼事都不幹，直接返回了。
-
如果newLockCount < 0，就拋異常，但是一般不會出現。
-
剩下的一種情況就是newLockCount == 0 ，說明鎖已經完完全全釋放完了，然後通過internals.releaseLock刪除加鎖的節點。
服務端刪除節點之後，就會通知監聽該節點的客戶端，然後客戶端就會回撥watcher監聽器，喚醒阻塞等待的執行緒，執行緒被喚醒後再進行一次判斷就能加鎖成功。
到這裡，就講完了加鎖和釋放鎖的過程，整個加鎖和釋放鎖的過程就如下圖所示。
八、如何實現公平鎖
其實使用臨時順序節點實現的分散式鎖就是公平鎖。所謂的公平鎖就是加鎖的順序跟成功加鎖的順序是一樣的。
因為節點的順序就是被喚醒的順序，所以也就是加鎖的順序，所以天生就是公平鎖。
九、如何實現讀寫鎖
讀寫鎖使用如下。
建立節點的時候，節點的內容中會有一個標記來代表當前節點加的是什麼型別的鎖。
當需要加寫鎖時，需要判斷自己建立的節點是否排在第一位，如果是就能加鎖成功，所以一旦前面有節點，不論前面加是讀鎖還是寫鎖，那麼都是加鎖失敗，實現了讀寫互斥和寫寫互斥。當然寫鎖和讀鎖都是可以重入加鎖的。
當需要加讀鎖的時候，會去判斷自己建立節點的前面有沒有寫鎖，如果沒寫鎖，那麼說明前面加的都是讀鎖，那麼讀鎖就能加鎖成功，讀讀不互斥，如果前面有寫鎖，那麼就加鎖失敗（自己加的寫鎖除外），讀寫互斥。
十、如何實現批量加鎖
批量加鎖的意思就是同時加幾個鎖，只有這些鎖都算加成功了，才是真正的加鎖成功。
Redisson也實現了批量加鎖的功能，Redisson的實現通過RedissonMultiLock類實現的，RedissonMultiLock會去遍歷需要加的鎖，然後每個都加成功之後才算加鎖成功。Curator是封裝了InterProcessMultiLock類來實現的批量加鎖的，那麼InterProcessMultiLock如何實現的呢？
使用程式碼如下。
InterProcessMultiLock的acquire的方法實現。
從這裡可以看出，InterProcessMultiLock也是遍歷傳入的鎖，然後每個鎖都加鎖成功了，InterProcessMultiLock才算加鎖成功。
所以從這裡可以看出，跟Redisson實現的批量加鎖的實現思想上基本是一樣的，都是遍歷加鎖。
十一、ZK分散式鎖和Redis分散式鎖到底該選誰
這是一個比較常見的面試題。
redis分散式鎖：
-
優點：效能高，能保證AP，保證其高可用，
-
缺點：正如Redisson的那篇文章所言，主要是如果出現主節點當機，從節點還未來得及同步主節點的加鎖資訊，可能會導致重複加鎖。雖然Redis官網提供了RedLock演算法來解決這個問題，Redisson也實現了，但是RedLock演算法其實本身是有一定的爭議的，有大佬質疑該演算法的可靠性；同時因為需要的機器過多，也會浪費資源，所以RedLock也不推薦使用。
zk分散式鎖：
-
優點：zk本身其實就是CP的，能夠保證加鎖資料的一致性。每個節點的建立都會同時寫入leader和follwer節點，半數以上寫入成功才返回，如果leader節點掛了之後選舉的流程會優先選舉zxid（事務Id）最大的節點，就是選資料最全的，又因為半數寫入的機制這樣就不會導致丟資料
-
缺點：效能沒有redis高
所以通過上面的對比可以看出，redis分散式鎖和zk分散式鎖的側重點是不同的，這是redis和zk本身的定位決定的，redis分散式鎖側重高效能，zk分散式鎖側重高可靠性。所以一般專案中redis分散式鎖和zk分散式鎖的選擇，是基於業務來決定的。如果你的業務需要保證加鎖的可靠性，不能出錯，那麼zk分散式鎖就比較符合你的要求；如果你的業務對於加鎖的可靠性沒有那麼高的要求，那麼redis分散式鎖是個不錯的選擇。
最後，希望通過這兩篇文章，讓大家對於zookeeper分散式鎖和redis分散式鎖的實現有個更好的認識。如需要Redisson原始碼剖析的文章，請關注微信公眾號 三友的java日記，回覆 Redisson 即可。
往期熱門文章推薦
掃碼或者搜尋關注公眾號 三友的java日記 ，及時乾貨不錯過，公眾號致力於通過畫圖加上通俗易懂的語言講解技術，讓技術更加容易學習。
