分散式之抉擇分散式鎖

作者：孤獨煙 出處：  http://rjzheng.cnblogs.com/

引言

為什麼寫這篇文章?

目前網上大部分的基於zookpeer，和redis的分散式鎖的文章都不夠全面。要麼就是特意避開叢集的情況，要麼就是考慮不全，讀者看著還是一臉迷茫。坦白說，這種老題材，很難寫出新創意，博主內心戰戰兢兢，如履薄冰，文中有什麼不嚴謹之處，歡迎批評。博主的這篇文章，不上程式碼，只講分析。

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

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

因為已經有開源jar包供你使用，沒有必要再去自己封裝一個，大家出門百度一個api即可，不需要再羅列一堆實現程式碼。需要說明的是，Google有一個名為Chubby的粗粒度分佈鎖的服務，然而，Google Chubby並不是開源的，我們只能通過其論文和其他相關的文件中瞭解具體的細節。值得慶幸的是，Yahoo!借鑑Chubby的設計思想開發了Zookeeper，並將其開源，因此本文不討論Chubby。至於Tair，是阿里開源的一個分散式K-V儲存方案。我們在工作中基本上redis使用的比較多，討論Tair所實現的分散式鎖，不具有代表性。

因此，主要分析的還是redis和zookpper所實現的分散式鎖。

文章結構

本文借鑑了兩篇國外大神的文章，redis的作者antirez的《 Is Redlock safe? 》以及分散式系統專家Martin的《 How to do distributed locking 》，再加上自己微薄的見解從而形成這篇文章，文章的目錄結構如下:

(1)為什麼使用分散式鎖

(2)單機情形比較

(3)叢集情形比較

(4)鎖的其他特性比較

正文

先上結論:zookpper可靠性比redis強太多，只是效率低了點，如果併發量不是特別大，追求可靠性，首選zookpeer。為了效率，則首選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)zookpeer

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

·當znode被宣告為EPHEMERAL的後，如果建立znode的那個客戶端崩潰了，那麼相應的znode會被自動刪除。這樣就避免了設定過期時間的問題。

·客戶端嘗試建立一個znode節點，比如/lock。那麼第一個客戶端就建立成功了，相當於拿到了鎖;而其它的客戶端會建立失敗(znode已存在)，獲取鎖失敗。

分析: 這種情況下，雖然避免了設定了有效時間問題，然而還是有可能出現多個客戶端操作共享資源的。大家應該知道，Zookpeer如果長時間檢測不到客戶端的心跳的時候(Session時間)，就會認為Session過期了，那麼這個Session所建立的所有的ephemeral型別的znode節點都會被自動刪除。這種時候會有如下情形出現

如上圖所示，客戶端1發生GC停頓的時候，zookpeer檢測不到心跳，也是有可能出現多個客戶端同時操作共享資源的情形。當然，你可以說，我們可以通過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)zookpeer

zookpeer在叢集部署中，zookpeer節點數量一般是奇數，且一定大等於3。我們先回憶一下，zookpeer的寫資料的原理

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

那麼寫資料流程步驟如下

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

2.Follwer把請求傳送給Leader

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

4.Follwer把投票結果傳送給Leader，只要半數以上返回了ACK資訊，就認為通過

5.Leader將結果彙總後如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然後commit;

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

還有一點，zookpeer採取的是全域性序列化操作

OK,現在開始分析

叢集同步

client給Follwer寫資料，可是Follwer卻當機了，會出現資料不一致問題麼?不可能，這種時候，client建立節點失敗，根本獲取不到鎖。client給Follwer寫資料，Follwer將請求轉發給Leader,Leader當機了，會出現不一致的問題麼?不可能，這種時候，zookpeer會選取新的leader,繼續上面的提到的寫流程。

總之，採用zookpeer作為分散式鎖，你要麼就獲取不到鎖，一旦獲取到了，必定節點的資料是一致的，不會出現redis那種非同步同步導致資料丟失的問題。

時間跳躍問題

不依賴全域性時間，怎麼會存在這種問題超時導致鎖失效問題不依賴有效時間，怎麼會存在這種問題

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

(1)redis的讀寫效能比zookpeer強太多，如果在高併發場景中，使用zookpeer作為分散式鎖，那麼會出現獲取鎖失敗的情況，存在效能瓶頸。

(2)zookpeer可以實現讀寫鎖，redis不行。

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

總結

OK，正文囉嗦了一大堆。其實只是想表明兩個觀點，無論是redis還是zookpeer，其實可靠性都存在一點問題。但是，zookpeer的分散式鎖的可靠性比redis強太多!但是,zookpeer讀寫效能不如redis,存在著效能瓶頸。大家在生產上使用，可自行進行評估使用。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31473948/viewspace-2157918/，如需轉載，請註明出處，否則將追究法律責任。