Redis中分布式鎖Redlock的示例分析

這篇文章主要介紹了Redis中分布式鎖Redlock的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

Redlock實現庫

• Java Redisson Star 9458

• C# RedLock.net Star 259

• Go redsync.go Star 249

雖然后面的算法是一樣的，不過這個點贊數確實服。

單點Redis鎖

先簡單回顧一下單點的Redis鎖是怎么實現的。

獲取鎖

SET resource_name my_random_value NX PX 30000

客戶端A在Redis上設置一個特定的鍵值對，同時給一個超時時間(避免死鎖)。其他客戶端在訪問的時候先看看這個key是否已經存在，并且值等于my_random_value。如果已存在就等待，否則就獲取成功，執行業務代碼。resource_name和my_random_value是所有客戶端都知道并且共享的。

釋放鎖

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

對比key獲取到的對應的value是否相等，如果相等，就刪除(釋放)，否則就返回失敗。

單點Redis鎖的缺陷

這個缺陷其實很明顯，如果只有一個Redis實例，這個掛了，所有依賴他的服務都掛了。顯然不太適合大型的應用。

簡單的Redis主從架構碰到的問題

為了避免單點故障，我們給Redis做一個Master/Slave的主從架構，一個Master，一臺Slave。下面就會碰到這么一個問題。下面是使用場景。

1. 客戶端A在Master上獲取到一個鎖。

2. Master把這個數據同步到Slave的時候掛了(因為Master和Slave之間同步是異步的)。

3. Slave變成了Master。

4. 客戶端B通過相同的key，和value獲取到鎖。分布式鎖失效

Redlock算法

假設我們有N(假設5)個Redis  master實例，所有節點相互獨立，并且業務系統也是單純的調用，并沒有什么其他的類似消息重發之類的輔助系統。下面來模擬一下算法：

     1.客戶端獲取服務器當前的的時間t0，毫秒數。

      2.使用相同的key和value依次向5個實例獲取鎖。客戶端在獲取鎖的時候自身設置一個遠小于業務鎖需要的持續時間的超時時間。舉個例子，假設鎖需要10秒，超時時間可以設置成比如5-50毫秒。這個避免某個Redis本身已經掛了，但是客戶端一直在嘗試獲取鎖的情況。超時了之后就直接跳到下一個節點。

      3.客戶端通過當前時間(t1)減去t0，計算獲取鎖所消耗的時間t2(=t1-t0)。只有t2小于鎖的業務有效時間(也就是第二步的10秒)，并且，客戶端在至少3(5/2+1)臺上獲取到鎖我們才認為鎖獲取成功。

      4.如果鎖已經獲取，那么鎖的業務有效時間為10s-t2。

      5.如果客戶端沒有獲取到鎖，可能是沒有在大于等于N/2+1個實例上獲取鎖，也可能是有效時間(10s-t2)為負數，我們就嘗試去釋放鎖，即使是并沒有在那個節點上獲取到。

鎖的釋放

釋放比較簡單，直接刪除所有實例上對應的key就好。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Redis中分布式鎖Redlock的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!