Redis分布式鎖(Redlock官方文檔的理解)

我github博客原文

官網解釋

分布式鎖在許多不同進程下需要對共享資源進行互斥操作的環境下，十分需要

Redis作者提出了 Redlock 算法

開始介紹：

安全和活躍度(可靠性)保障(Safety and Liveness)

需要設計合理分布式鎖，并滿足基本的保障 1.安全 -> 互斥屬性，在任何條件下，只允許一個客戶端拿到鎖 2.活躍度(可靠性)A -> 死鎖檢測，即使有獲取到鎖的客戶端崩潰或者不可用，但是最終鎖還是能被獲取到 3.活躍度(可靠性)B -> 容錯，只要大部分的redis節點都存活，客戶端就能夠獲取鎖和釋放鎖 復制代碼

為什么故障恢復的實現還不足夠

有個Master + slave 1.客戶端A獲取鎖 2.master 在命令傳播給slave前就崩潰了 3.slave這時候還不存在key，所以當它被晉升成master時 4.客戶端B嘗試獲取鎖，就被獲取到了-> 這時候就不滿足redis分布式鎖的安全性了在極端情況下，集群服務發生失敗時，多客戶端可能同時獲取鎖 復制代碼

單實例的正確實現

在解決上述問題前，先把基本的redis分布式鎖的設計做好

當我們獲取鎖的時候，執行下面命令行:

SET resource_name my_random_value NX PX 30000 NX表示當key不存在才能設置成功 PX表示超時時間 my_random_value 需要在所有客戶端和獲取鎖的請求中表示唯一 復制代碼

釋放鎖,需要帶著 my_random_value 作標識然后再del，2個操作作原子，所以推薦使用lua腳本

if redis.call("get",KEYS[1]) == ARGV[1] thenreturn redis.call("del",KEYS[1]) elsereturn 0 end 復制代碼

說明

1.這樣就能有效的阻止其他客戶端生成鎖。(應該不用多說明吧。) 2.my_random_value 應該怎么設置，反正容量越小，消耗越小越好，文檔上給出是使用clientId加上時間戳或者使用RC4算法 3.expire的時間設置，我們稱作鎖有效時間，是鎖自動釋放時間 + 客戶端需要在鎖時間內執行的事務所需要的時間(在其他客戶端獲取到鎖之前) = 鎖自動釋放時間 + 客戶端處理業務(鎖期間)的時間 考慮到互斥的保證，這個時間窗口應該限制在鎖被獲取之后復制代碼

基本操作介紹了，現在可以優化了

Redlock算法

在分布式版本中，我們假設我們有N個redis 的matser，各自獨立，沒有任何關系(不在一個cluster下)，可以部署在不同的服務器或是虛擬機上，假設N設置成5客戶端獲取鎖的操作： 1. 客戶端A獲取當前時間戳 2. 客戶端A嘗試在所有N個redis中獲取鎖(有序的)，使用同樣的key和value，這一步中，由于需要遍歷去請求多個redis服務(set的命令請求，之前理解成業務的處理時間)，可能導致阻塞，需要設置超時時間，假設鎖自動釋放的時間是10s，那么這個超時時間可以設置在 5-50毫秒范圍，這一步，防止客戶端在獲取鎖期間由于redis節點崩潰不可用導致獲取鎖曹氏 3. 客戶端A獲取鎖時，再獲取當前時間戳，與步驟1的時間相減，得到獲取鎖消耗的時間，在鎖有效期內，當且僅當客戶端A拿到大部分(至少3)的鎖時，分布式鎖才可以被正式獲取 4. 每次當鎖被獲取到時(從每個master獲取)，有效時間可以被設置成初始有效時間減去獲取鎖消耗的時間 (因為已經獲取鎖了，所以獲取鎖的時間不用算進去) 5. 假設在步驟2中客戶端A獲取不到鎖，比如拿不到大部分的鎖，或者是鎖還沒超時，它需要把自己在少部分redis上拿到的鎖釋放掉復制代碼

這個算法是異步的嗎

這個算法依賴的一個假設：是不同進程的各自的時鐘精確率(就是表走得快走得慢，而且誤差跟鎖釋放時間比小得多)一樣，而且不(需要)作時間的同步。類似于，現實生活中，每個人都各自使用自己的電腦(以及電腦上的時間)，通常也不會有什么問題； 在這個情況下，我們需要更具體的說明互斥規則：它(互斥規則)保證僅僅只有獲取鎖的哭護短能夠在鎖的有效時間內結束它的工作，減去某個很小的時間差(幾毫秒，用來作補償)復制代碼

失敗重試(這里指的是獲取鎖的失敗)

當客戶端獲取不到鎖，它應該在之后一個隨機時間點重試，這為了避免多個客戶端嘗試同時獲取同一個資源(類似腦裂的情況，大概意思就是競爭了一堆，卻發現，沒人拿到鎖)，客戶端拿到鎖越快(早)，腦裂的情況越小(或者重試的需要越小)，所以理想情況下，客戶端可以同時(多路復用)發送set命令給各個master復制代碼

釋放鎖

鎖釋放步驟很簡單，就是把所有master實例上的鎖釋放，并不需要關心客戶端在該實例上有沒有成功得到鎖復制代碼

安全討論

假設一個客戶端能夠獲取大多數實例上的鎖，所有實例都會存在一個key，并且有個相同的超時時間，但是這個key的設置的時間點是不一樣的(就是set的時候都不一樣，因為是順序執行，總會有時間差)，所以key會在不同的時間超時。但是當第一個key被至少設成T1，最后一個key被設成T2(超時時間)，我們可以確認第一個key會存在至少 MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT 的時間，而且其他的key會失效的更晚，我們要同時將時間設置成這個 當一個key被set(NX)的時候，其他key就無法被別的客戶端set了---- 總的說的就是時間設置還有并發控制 復制代碼

可靠性討論

1. 自動釋放的鎖最終還能被獲取到； 2. 客戶端通常會協助刪除那些沒獲取到的鎖(步驟5)、鎖獲取到并且工作結束的，使得并不需要等待鎖超時才能重新獲取鎖； 3. 客戶端需要重試獲取鎖，為了資源競爭，他們重試的等待時間應該大于需要從大多數實例上獲取的時間復制代碼 《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Redis分布式锁(Redlock官方文档的理解)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。