一、基於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就崩潰了，也會自動釋放鎖。

喜歡小編輕輕點個關註吧！

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