深刻理解分佈式之抉擇分佈式鎖

 

引言

爲何寫這篇文章？

目前網上大部分的基於zookeeper，和redis的分佈式鎖的文章都不夠全面。要麼就是特地避開集羣的狀況，要麼就是考慮不全，讀者看着仍是一臉迷茫。坦白說，這種老題材，很難寫出新創意，博主心裏戰戰兢兢，如履薄冰，文中有什麼不嚴謹之處，歡迎批評。

博主的這篇文章，不上代碼，只講分析。

(1)在redis方面，有開源redisson的jar包供你使用。

(2)在zookeeper方面，有開源的curator的jar包供你使用

由於已經有開源jar包供你使用，沒有必要再去本身封裝一個，你們出門百度一個api便可，不須要再羅列一堆實現代碼。

須要說明的是，Google有一個名爲Chubby的粗粒度分佈鎖的服務，然而，Google Chubby並非開源的，咱們只能經過其論文和其餘相關的文檔中瞭解具體的細節。值得慶幸的是，Yahoo！借鑑Chubby的設計思想開發了zookeeper，並將其開源，所以本文不討論Chubby。至於Tair，是阿里開源的一個分佈式K-V存儲方案。咱們在工做中基本上redis使用的比較多，討論Tair所實現的分佈式鎖，不具備表明性。

所以，主要分析的仍是redis和zookeeper所實現的分佈式鎖。

文章結構

本文借鑑了兩篇國外大神的文章，redis的做者antirez的《Is Redlock safe?》以及分佈式系統專家Martin的《How to do distributed locking》，再加上本身微薄的看法從而造成這篇文章，文章的目錄結構以下:

(1)爲何使用分佈式鎖

(2)單機情形比較

(3)集羣情形比較

(4)鎖的其餘特性比較

正文

先上結論:

zookeeper可靠性比redis強太多，只是效率低了點，若是併發量不是特別大，追求可靠性，首選zookeeper。爲了效率，則首選redis實現。

爲何使用分佈式鎖？

使用分佈式鎖的目的，無外乎就是保證同一時間只有一個客戶端能夠對共享資源進行操做。

可是Martin指出，根據鎖的用途還能夠細分爲如下兩類

(1)容許多個客戶端操做共享資源

這種狀況下，對共享資源的操做必定是冪等性操做，不管你操做多少次都不會出現不一樣結果。在這裏使用鎖，無外乎就是爲了不重複操做共享資源從而提升效率。

(2)只容許一個客戶端操做共享資源

這種狀況下，對共享資源的操做通常是非冪等性操做。在這種狀況下，若是出現多個客戶端操做共享資源，就可能意味着數據不一致，數據丟失。

第一回合，單機情形比較

(1)redis

先說加鎖，根據redis官網文檔的描述，使用下面的命令加鎖

SET resource_name my_random_value NX PX 30000

• my_random_value是由客戶端生成的一個隨機字符串，至關因而客戶端持有鎖的標誌
• NX表示只有當resource_name對應的key值不存在的時候才能SET成功，至關於只有第一個請求的客戶端才能得到鎖
• PX 30000表示這個鎖有一個30秒的自動過時時間。

至於解鎖，爲了防止客戶端1得到的鎖，被客戶端2給釋放,採用下面的Lua腳原本釋放鎖

if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end

在執行這段LUA腳本的時候，KEYS[1]的值爲resource_name，ARGV[1]的值爲my_random_value。原理就是先獲取鎖對應的value值，保證和客戶端穿進去的my_random_value值相等，這樣就能避免本身的鎖被其餘人釋放。另外，採起Lua腳本操做保證了原子性.若是不是原子性操做，則有了下述狀況出現

 

分析:這套redis加解鎖機制看起來很完美，然而有一個沒法避免的硬傷，就是過時時間如何設置。若是客戶端在操做共享資源的過程當中，由於長期阻塞的緣由，致使鎖過時，那麼接下來訪問共享資源就不安全。

但是，有的人會說

那能夠在客戶端操做完共享資源後，判斷鎖是否依然歸該客戶端全部，若是依然歸客戶端全部，則提交資源，釋放鎖。若不歸客戶端全部，則不提交資源啊.

OK,這麼作，只能下降多個客戶端操做共享資源發生的機率，並不能解決問題。

爲了方便讀者理解，博主舉一個業務場景。

業務場景:咱們有一個內容修改頁面，爲了不出現多個客戶端修改同一個頁面的請求，採用分佈式鎖。只有得到鎖的客戶端，才能修改頁面。那麼正常修改一次頁面的流程以下圖所示

 

注意看，上面的步驟(3)-->步驟(4.1)並非原子性操做。也就說，你可能出如今步驟(3)的時候返回的是有效這個標誌位，可是在傳輸過程當中，由於延時等緣由，在步驟(4.1)的時候，鎖已經超時失效了。那麼，這個時候鎖就會被另外一個客戶端鎖得到。就出現了兩個客戶端共同操做共享資源的狀況。

你們能夠思考一下，不管你如何採用任何補償手段，你都只能下降多個客戶端操做共享資源的機率，而沒法避免。例如，你在步驟(4.1)的時候也可能發生長時間GC停頓，而後在停頓的時候，鎖超時失效，從而鎖也有可能被其餘客戶端得到。這些你們能夠自行思考推敲。

(2)zookeeper

先簡單說下原理，根據網上文檔描述，zookeeper的分佈式鎖原理是利用了臨時節點(EPHEMERAL)的特性。

• 當znode被聲明爲EPHEMERAL的後，若是建立znode的那個客戶端崩潰了，那麼相應的znode會被自動刪除。這樣就避免了設置過時時間的問題。
• 客戶端嘗試建立一個znode節點，好比/lock。那麼第一個客戶端就建立成功了，至關於拿到了鎖；而其它的客戶端會建立失敗（znode已存在），獲取鎖失敗。

分析:這種狀況下，雖然避免了設置了有效時間問題，然而仍是有可能出現多個客戶端操做共享資源的。

你們應該知道，zookeeper若是長時間檢測不到客戶端的心跳的時候(Session時間)，就會認爲Session過時了，那麼這個Session所建立的全部的ephemeral類型的znode節點都會被自動刪除。

這種時候會有以下情形出現

 

如上圖所示，客戶端1發生GC停頓的時候，zookeeper檢測不到心跳，也是有可能出現多個客戶端同時操做共享資源的情形。固然，你能夠說，咱們能夠經過JVM調優，避免GC停頓出現。可是注意了，咱們所作的一切，只能儘量避免多個客戶端操做共享資源，沒法徹底消除。

第二回合，集羣情形比較

咱們在生產中，通常都是用集羣情形，因此第一回合討論的單機情形。算是給你們熱熱身。

(1)redis

爲了redis的高可用，通常都會給redis的節點掛一個slave,而後採用哨兵模式進行主備切換。但因爲Redis的主從複製（replication）是異步的，這可能會出如今數據同步過程當中，master宕機，slave來不及同步數據就被選爲master，從而數據丟失。具體流程以下所示:

• (1)客戶端1從Master獲取了鎖。
• (2)Master宕機了，存儲鎖的key尚未來得及同步到Slave上。
• (3)Slave升級爲Master。
• (4)客戶端2重新的Master獲取到了對應同一個資源的鎖。

爲了應對這個情形， redis的做者antirez提出了RedLock算法，步驟以下(該流程出自官方文檔)，假設咱們有N個master節點(官方文檔裏將N設置成5，其實大等於3就行)

• (1)獲取當前時間（單位是毫秒）。
• (2)輪流用相同的key和隨機值在N個節點上請求鎖，在這一步裏，客戶端在每一個master上請求鎖時，會有一個和總的鎖釋放時間相比小的多的超時時間。好比若是鎖自動釋放時間是10秒鐘，那每一個節點鎖請求的超時時間多是5-50毫秒的範圍，這個能夠防止一個客戶端在某個宕掉的master節點上阻塞過長時間，若是一個master節點不可用了，咱們應該儘快嘗試下一個master節點。
• (3)客戶端計算第二步中獲取鎖所花的時間，只有當客戶端在大多數master節點上成功獲取了鎖（在這裏是3個），並且總共消耗的時間不超過鎖釋放時間，這個鎖就認爲是獲取成功了。
• (4)若是鎖獲取成功了，那如今鎖自動釋放時間就是最初的鎖釋放時間減去以前獲取鎖所消耗的時間。
• (5)若是鎖獲取失敗了，無論是由於獲取成功的鎖不超過一半（N/2+1)仍是由於總消耗時間超過了鎖釋放時間，客戶端都會到每一個master節點上釋放鎖，即使是那些他認爲沒有獲取成功的鎖。

分析:RedLock算法細想一下還存在下面的問題

節點崩潰重啓，會出現多個客戶端持有鎖

假設一共有5個Redis節點：A, B, C, D, E。設想發生了以下的事件序列：

(1)客戶端1成功鎖住了A, B, C，獲取鎖成功（但D和E沒有鎖住）。

(2)節點C崩潰重啓了，但客戶端1在C上加的鎖沒有持久化下來，丟失了。

(3)節點C重啓後，客戶端2鎖住了C, D, E，獲取鎖成功。

這樣，客戶端1和客戶端2同時得到了鎖（針對同一資源）。

爲了應對節點重啓引起的鎖失效問題，redis的做者antirez提出了延遲重啓的概念，即一個節點崩潰後，先不當即重啓它，而是等待一段時間再重啓，等待的時間大於鎖的有效時間。採用這種方式，這個節點在重啓前所參與的鎖都會過時，它在重啓後就不會對現有的鎖形成影響。這其實也是經過人爲補償措施，下降不一致發生的機率。

時間跳躍問題

(1)假設一共有5個Redis節點：A, B, C, D, E。設想發生了以下的事件序列：

(2)客戶端1從Redis節點A, B, C成功獲取了鎖（多數節點）。因爲網絡問題，與D和E通訊失敗。

(3)節點C上的時鐘發生了向前跳躍，致使它上面維護的鎖快速過時。

客戶端2從Redis節點C, D, E成功獲取了同一個資源的鎖（多數節點）。

客戶端1和客戶端2如今都認爲本身持有了鎖。

爲了應對始終跳躍引起的鎖失效問題，redis的做者antirez提出了應該禁止人爲修改系統時間，使用一個不會進行「跳躍」式調整系統時鐘的ntpd程序。這也是經過人爲補償措施，下降不一致發生的機率。

超時致使鎖失效問題

RedLock算法並無解決，操做共享資源超時，致使鎖失效的問題。回憶一下RedLock算法的過程，以下圖所示

 

如圖所示，咱們將其分爲上下兩個部分。對於上半部分框圖裏的步驟來講，不管由於什麼緣由發生了延遲，RedLock算法都能處理，客戶端不會拿到一個它認爲有效，實際卻失效的鎖。然而，對於下半部分框圖裏的步驟來講，若是發生了延遲致使鎖失效，都有可能使得客戶端2拿到鎖。所以，RedLock算法並無解決該問題。

(2)zookeeper

zookeeper在集羣部署中，zookeeper節點數量通常是奇數，且必定大等於3。咱們先回憶一下，zookeeper的寫數據的原理

如圖所示，這張圖懶得畫，直接搬其餘文章的了。

 

那麼寫數據流程步驟以下

1.在Client向Follwer發出一個寫的請求

2.Follwer把請求發送給Leader

3.Leader接收到之後開始發起投票並通知Follwer進行投票

4.Follwer把投票結果發送給Leader，只要半數以上返回了ACK信息，就認爲經過

5.Leader將結果彙總後若是須要寫入，則開始寫入同時把寫入操做通知給Leader，而後commit;

6.Follwer把請求結果返回給Client

7.給你們推薦一個架構交流qq羣：698581634 進羣便可免費獲取資料，有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。

還有一點，zookeeper採起的是全局串行化操做

OK,如今開始分析

集羣同步

client給Follwer寫數據，但是Follwer卻宕機了，會出現數據不一致問題麼？不可能，這種時候，client創建節點失敗，根本獲取不到鎖。

client給Follwer寫數據，Follwer將請求轉發給Leader,Leader宕機了，會出現不一致的問題麼？不可能，這種時候，zookeeper會選取新的leader,繼續上面的提到的寫流程。

總之，採用zookeeper做爲分佈式鎖，你要麼就獲取不到鎖，一旦獲取到了，一定節點的數據是一致的，不會出現redis那種異步同步致使數據丟失的問題。

時間跳躍問題

不依賴全局時間，怎麼會存在這種問題

超時致使鎖失效問題

不依賴有效時間，怎麼會存在這種問題

第三回合，鎖的其餘特性比較

(1)redis的讀寫性能比zookeeper強太多，若是在高併發場景中，使用zookeeper做爲分佈式鎖，那麼會出現獲取鎖失敗的狀況，存在性能瓶頸。

(2)zookeeper能夠實現讀寫鎖，redis不行。

(3)zookeeper的watch機制,客戶端試圖建立znode的時候，發現它已經存在了，這時候建立失敗,那麼進入一種等待狀態，當znode節點被刪除的時候，zookeeper經過watch機制通知它，這樣它就能夠繼續完成建立操做（獲取鎖）。這可讓分佈式鎖在客戶端用起來就像一個本地的鎖同樣：加鎖失敗就阻塞住，直到獲取到鎖爲止。這套機制，redis沒法實現

總結

OK，正文囉嗦了一大堆。其實只是想代表兩個觀點，不管是redis仍是zookeeper，其實可靠性都存在一點問題。可是，zookeeper的分佈式鎖的可靠性比redis強太多！可是,zookeeper讀寫性能不如redis,存在着性能瓶頸。你們在生產上使用，可自行進行評估使用。