分散式Redis的分散式鎖 Redlock

引言

之前自己在用redis來實現分散式鎖的時候都是基於單個Redis實體，也就是說Redis本身是有單點故障的，Redis的官方檔案介紹了一種”自認為”合理的演演算法，Redlock來實現分散式Redis下的分散式鎖。

Martin Kleppmann寫了一篇文章分析Redlock。然後redis的作者寫了一篇反駁的文章這裡。加油。

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 0
end

對比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就好。

分享