基於redis和zookeeper的分散式鎖實現方式

【本文轉自部落格園 作者：姜泮昌  原文連結：https://www.cnblogs.com/jpcflyer/p/9142813.html】
先來說說什麼是分散式鎖，簡單來說，分散式鎖就是在分散式併發場景中，能夠實現多節點的程式碼同步的一種機制。從實現角度來看，主要有兩種方式：基於redis的方式和基於zookeeper的方式，下面分別簡單介紹下這兩種方式：

　　一、基於redis的分散式鎖實現

　　1.獲取鎖

　　redis是一種key-value形式的NOSQL資料庫，常用於作伺服器的快取。從redis v2.6.12開始，set命令開始變成如下格式：

　　SET key value [EX seconds] [PX milliseconds] [NX|XX]

　　除key和value外，EX是超時時間，NX表示只有在key不存在的時候才會設定key的值，而XX表示在key存在的時間才會設定key的值。NX機制就是基於redis分散式鎖的核心。能夠解決以下問題：

　　1)節點1獲取key，並且設定超時時間後，還沒來得及釋放就掛掉了——這裡EX超時時間會發揮作用，超時後自動釋放鎖。

　　2)剛獲取到鎖，還沒來得及設定超時時間就掛了——這裡設定key和設定超時時間是原子操作，如果出現這種情況，會返回0，即獲取不到鎖。

　　2.釋放鎖

　　為了解決非原子操作帶來的問題，常採用lua指令碼實現。lua指令碼的操作會被認為是原子性的，類似於事務。虛擬碼如下：

　　二、基於zookeeper的分散式鎖實現

　　zookeeper是一種分散式協調服務，其中每個節點稱為znode，並有自己獨立的路徑。 znode有四種型別：

　　持久節點：預設的節點型別。建立節點的客戶端與zookeeper斷開連線後，該節點依舊存在 。

　　持久節點順序節點：所謂順序節點，就是在建立節點時，Zookeeper根據建立的時間順序給該節點名稱進行編號：

　　臨時節點：和持久節點相反，當建立節點的客戶端與zookeeper斷開連線後，臨時節點會被刪除：

　　臨時順序節點：結合和臨時節點和順序節點的特點：在建立節點時，Zookeeper根據建立的時間順序給該節點名稱進行編號;當建立節點的客戶端與zookeeper斷開連線後，臨時節點會被刪除。

　　下面看看是怎樣基於上面的四類節點實現分散式鎖的。

　　1.獲取鎖

　　1)在Zookeeper當中建立一個持久節,當第一個客戶端Client1想要獲得鎖時,需要在這個節點下面建立一個臨時順序節點。

　　2)Client1查詢持久節點下面所有的臨時順序節點並排序，判斷自己所建立的節點是不是順序最靠前的一個。如果是第一個節點，則成功獲得鎖。

　　3)如果再有一個客戶端 Client2 前來獲取鎖，則在持久節點下面再建立一個臨時順序節點Lock2。

　　4)Client2查詢持久節點下面所有的臨時順序節點並排序，判斷自己所建立的節點Lock2是不是順序最靠前的一個，結果發現節點Lock2並不是最小的。

　　於是，Client2向排序僅比它靠前的節點Lock1註冊Watcher，用於監聽Lock1節點是否存在。這意味著Client2搶鎖失敗，進入了等待狀態。

　　5)如果又有一個客戶端Client3前來獲取鎖，則在持久節點下載再建立一個臨時順序節點Lock3。

　　Client3查詢持久節點下面所有的臨時順序節點並排序，判斷自己所建立的節點Lock3是不是順序最靠前的一個，結果同樣發現節點Lock3並不是最小的。

　　於是，Client3向排序僅比它靠前的節點Lock2註冊Watcher，用於監聽Lock2節點是否存在。這意味著Client3同樣搶鎖失敗，進入了等待狀態。

　　2.釋放鎖

　　釋放鎖就比較簡單了，因為前面建立的臨時順序節點，所以在出現下面兩種情況時，都會自動釋放鎖：

　　1)任務完成後，Client會釋放鎖。

　　2)任務沒完成，Client就崩潰了，也會自動釋放鎖。