本篇內容介紹了“怎么理解redis抉擇分布式鎖”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

創(chuàng)新互聯(lián)公司專注于點軍企業(yè)網站建設,成都響應式網站建設公司,商城網站制作。點軍網站建設公司,為點軍等地區(qū)提供建站服務。全流程按需搭建網站，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務

zookeeper可靠性比redis強太多，只是效率低了點，如果并發(fā)量不是特別大，追求可靠性，選zookeeper。為了效率，則選redis實現(xiàn)。

為什么使用分布式鎖？

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

但是Martin指出，根據鎖的用途還可以細分為以下兩類

(1)允許多個客戶端操作共享資源

這種情況下，對共享資源的操作一定是冪等性操作，無論你操作多少次都不會出現(xiàn)不同結果。在這里使用鎖，無外乎就是為了避免重復操作共享資源從而提高效率。

(2)只允許一個客戶端操作共享資源

這種情況下，對共享資源的操作一般是非冪等性操作。在這種情況下，如果出現(xiàn)多個客戶端操作共享資源，就可能意味著數(shù)據不一致，數(shù)據丟失。

第一回合，單機情形比較

(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

在執(zhí)行這段LUA腳本的時候，KEYS[1]的值為resource_name，ARGV[1]的值為my_random_value。原理就是先獲取鎖對應的value值，保證和客戶端穿進去的my_random_value值相等，這樣就能避免自己的鎖被其他人釋放。另外，采取Lua腳本操作保證了原子性.如果不是原子性操作，則有了下述情況出現(xiàn)

分析:這套redis加解鎖機制看起來很完美，然而有一個無法避免的硬傷，就是過期時間如何設置。如果客戶端在操作共享資源的過程中，因為長期阻塞的原因，導致鎖過期，那么接下來訪問共享資源就不安全。

可是，有的人會說

那可以在客戶端操作完共享資源后，判斷鎖是否依然歸該客戶端所有，如果依然歸客戶端所有，則提交資源，釋放鎖。若不歸客戶端所有，則不提交資源啊.

OK,這么做，只能降低多個客戶端操作共享資源發(fā)生的概率，并不能解決問題。

為了方便讀者理解，博主舉一個業(yè)務場景。

業(yè)務場景:我們有一個內容修改頁面，為了避免出現(xiàn)多個客戶端修改同一個頁面的請求，采用分布式鎖。只有獲得鎖的客戶端，才能修改頁面。那么正常修改一次頁面的流程如下圖所示

注意看，上面的步驟(3)-->步驟(4.1)并不是原子性操作。也就說，你可能出現(xiàn)在步驟(3)的時候返回的是有效這個標志位，但是在傳輸過程中，因為延時等原因，在步驟(4.1)的時候，鎖已經超時失效了。那么，這個時候鎖就會被另一個客戶端鎖獲得。就出現(xiàn)了兩個客戶端共同操作共享資源的情況。

大家可以思考一下，無論你如何采用任何補償手段，你都只能降低多個客戶端操作共享資源的概率，而無法避免。例如，你在步驟(4.1)的時候也可能發(fā)生長時間GC停頓，然后在停頓的時候，鎖超時失效，從而鎖也有可能被其他客戶端獲得。這些大家可以自行思考推敲。

(2)zookeeper

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

• 當znode被聲明為EPHEMERAL的后，如果創(chuàng)建znode的那個客戶端崩潰了，那么相應的znode會被自動刪除。這樣就避免了設置過期時間的問題。

• 客戶端嘗試創(chuàng)建一個znode節(jié)點，比如/lock。那么第一個客戶端就創(chuàng)建成功了，相當于拿到了鎖；而其它的客戶端會創(chuàng)建失敗（znode已存在），獲取鎖失敗。

分析:這種情況下，雖然避免了設置了有效時間問題，然而還是有可能出現(xiàn)多個客戶端操作共享資源的。

大家應該知道，zookeeper如果長時間檢測不到客戶端的心跳的時候(Session時間)，就會認為Session過期了，那么這個Session所創(chuàng)建的所有的ephemeral類型的znode節(jié)點都會被自動刪除。

這種時候會有如下情形出現(xiàn)

如上圖所示，客戶端1發(fā)生GC停頓的時候，zookeeper檢測不到心跳，也是有可能出現(xiàn)多個客戶端同時操作共享資源的情形。當然，你可以說，我們可以通過JVM調優(yōu)，避免GC停頓出現(xiàn)。但是注意了，我們所做的一切，只能盡可能避免多個客戶端操作共享資源，無法完全消除。

第二回合，集群情形比較

我們在生產中，一般都是用集群情形，所以第一回合討論的單機情形。算是給大家熱熱身。

(1)redis

為了redis的高可用，一般都會給redis的節(jié)點掛一個slave,然后采用哨兵模式進行主備切換。但由于Redis的主從復制（replication）是異步的，這可能會出現(xiàn)在數(shù)據同步過程中，master宕機，slave來不及同步數(shù)據就被選為master，從而數(shù)據丟失。具體流程如下所示:

• (1)客戶端1從Master獲取了鎖。

• (2)Master宕機了，存儲鎖的key還沒有來得及同步到Slave上。

• (3)Slave升級為Master。

• (4)客戶端2從新的Master獲取到了對應同一個資源的鎖。

為了應對這個情形， redis的作者antirez提出了RedLock算法，步驟如下(該流程出自官方文檔)，假設我們有N個master節(jié)點(官方文檔里將N設置成5，其實大等于3就行)

• (1)獲取當前時間（單位是毫秒）。

• (2)輪流用相同的key和隨機值在N個節(jié)點上請求鎖，在這一步里，客戶端在每個master上請求鎖時，會有一個和總的鎖釋放時間相比小的多的超時時間。比如如果鎖自動釋放時間是10秒鐘，那每個節(jié)點鎖請求的超時時間可能是5-50毫秒的范圍，這個可以防止一個客戶端在某個宕掉的master節(jié)點上阻塞過長時間，如果一個master節(jié)點不可用了，我們應該盡快嘗試下一個master節(jié)點。

• (3)客戶端計算第二步中獲取鎖所花的時間，只有當客戶端在大多數(shù)master節(jié)點上成功獲取了鎖（在這里是3個），而且總共消耗的時間不超過鎖釋放時間，這個鎖就認為是獲取成功了。

• (4)如果鎖獲取成功了，那現(xiàn)在鎖自動釋放時間就是最初的鎖釋放時間減去之前獲取鎖所消耗的時間。

• (5)如果鎖獲取失敗了，不管是因為獲取成功的鎖不超過一半（N/2+1)還是因為總消耗時間超過了鎖釋放時間，客戶端都會到每個master節(jié)點上釋放鎖，即便是那些他認為沒有獲取成功的鎖。

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

節(jié)點崩潰重啟，會出現(xiàn)多個客戶端持有鎖

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

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

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

(3)節(jié)點C重啟后，客戶端2鎖住了C, D, E，獲取鎖成功。

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

為了應對節(jié)點重啟引發(fā)的鎖失效問題，redis的作者antirez提出了延遲重啟的概念，即一個節(jié)點崩潰后，先不立即重啟它，而是等待一段時間再重啟，等待的時間大于鎖的有效時間。采用這種方式，這個節(jié)點在重啟前所參與的鎖都會過期，它在重啟后就不會對現(xiàn)有的鎖造成影響。這其實也是通過人為補償措施，降低不一致發(fā)生的概率。

時間跳躍問題

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

(2)客戶端1從Redis節(jié)點A, B, C成功獲取了鎖（多數(shù)節(jié)點）。由于網絡問題，與D和E通信失敗。

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

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

客戶端1和客戶端2現(xiàn)在都認為自己持有了鎖。

為了應對始終跳躍引發(fā)的鎖失效問題，redis的作者antirez提出了應該禁止人為修改系統(tǒng)時間，使用一個不會進行“跳躍”式調整系統(tǒng)時鐘的ntpd程序。這也是通過人為補償措施，降低不一致發(fā)生的概率。

超時導致鎖失效問題

RedLock算法并沒有解決，操作共享資源超時，導致鎖失效的問題。回憶一下RedLock算法的過程，如下圖所示

如圖所示，我們將其分為上下兩個部分。對于上半部分框圖里的步驟來說，無論因為什么原因發(fā)生了延遲，RedLock算法都能處理，客戶端不會拿到一個它認為有效，實際卻失效的鎖。然而，對于下半部分框圖里的步驟來說，如果發(fā)生了延遲導致鎖失效，都有可能使得客戶端2拿到鎖。因此，RedLock算法并沒有解決該問題。

(2)zookeeper

zookeeper在集群部署中，zookeeper節(jié)點數(shù)量一般是奇數(shù)，且一定大等于3。我們先回憶一下，zookeeper的寫數(shù)據的原理

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

那么寫數(shù)據流程步驟如下

1.在Client向Follwer發(fā)出一個寫的請求

2.Follwer把請求發(fā)送給Leader

3.Leader接收到以后開始發(fā)起投票并通知Follwer進行投票

4.Follwer把投票結果發(fā)送給Leader，只要半數(shù)以上返回了ACK信息，就認為通過

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

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

7.給大家推薦一個架構交流qq群：698581634 進群即可免費獲取資料，有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務架構的原理，JVM性能優(yōu)化、分布式架構等這些成為架構師必備的知識體系。

還有一點，zookeeper采取的是全局串行化操作

OK,現(xiàn)在開始分析

集群同步

client給Follwer寫數(shù)據，可是Follwer卻宕機了，會出現(xiàn)數(shù)據不一致問題么？不可能，這種時候，client建立節(jié)點失敗，根本獲取不到鎖。

client給Follwer寫數(shù)據，F(xiàn)ollwer將請求轉發(fā)給Leader,Leader宕機了，會出現(xiàn)不一致的問題么？不可能，這種時候，zookeeper會選取新的leader,繼續(xù)上面的提到的寫流程。

總之，采用zookeeper作為分布式鎖，你要么就獲取不到鎖，一旦獲取到了，必定節(jié)點的數(shù)據是一致的，不會出現(xiàn)redis那種異步同步導致數(shù)據丟失的問題。

時間跳躍問題

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

超時導致鎖失效問題

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

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

(1)redis的讀寫性能比zookeeper強太多，如果在高并發(fā)場景中，使用zookeeper作為分布式鎖，那么會出現(xiàn)獲取鎖失敗的情況，存在性能瓶頸。

(2)zookeeper可以實現(xiàn)讀寫鎖，redis不行。

(3)zookeeper的watch機制,客戶端試圖創(chuàng)建znode的時候，發(fā)現(xiàn)它已經存在了，這時候創(chuàng)建失敗,那么進入一種等待狀態(tài)，當znode節(jié)點被刪除的時候，zookeeper通過watch機制通知它，這樣它就可以繼續(xù)完成創(chuàng)建操作（獲取鎖）。這可以讓分布式鎖在客戶端用起來就像一個本地的鎖一樣：加鎖失敗就阻塞住，直到獲取到鎖為止。這套機制，redis無法實現(xiàn)

“怎么理解redis抉擇分布式鎖”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)-成都網站建設公司網站，小編將為大家輸出更多高質量的實用文章！

網頁標題：怎么理解redis抉擇分布式鎖-創(chuàng)新互聯(lián)
網站鏈接：http://jinyejixie.com/article30/jeopo.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站維護、網站設計公司、自適應網站、全網營銷推廣、動態(tài)網站、外貿建站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)