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

標籤：編號   基於   結合   str   watch   返回   核心   情況   格式   

先來說說什麼是分布式鎖，簡單來說，分布式鎖就是在分布式並發情境中，能夠實現多節點的代碼同步的一種機制。從實現角度來看，主要有兩種方式：基於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就崩潰了，也會自動釋放鎖。

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

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