分布式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 0end
對比key獲取到的對應的value是否相等，如果相等，就刪除(釋放)，否則就返回失敗。
之前也寫過一篇文章。
單點Redis鎖的缺陷
這個缺陷其實很明顯，如果只有一個Redis實例，這個掛了，所有依賴他的服務都掛了。顯然不太適合大型的應用。
簡單的Redis主從架構碰到的問題
為了避免單點故障，我們給Redis做一個Master/Slave的主從架構，一個Master，一臺Slave。下面就會碰到這么一個問題。下面是使用場景。
- 客戶端A在Master上獲取到一個鎖。
- Master把這個數據同步到Slave的時候掛了(因為Master和Slave之間同步是異步的)。
- Slave變成了Master。
- 客戶端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就好。喜歡文章的可以點個關注喲，感謝你的閱讀!
