建站
咨詢
售后
建站咨詢
新聞中心
Redis 分布式鎖沒這么簡單，網(wǎng)上大多數(shù)都有 bug
作者：碼哥字節(jié) 2021-11-11 07:47:03
存儲
存儲軟件
分布式
Redis 分布式鎖就是用來控制同一時刻，只有一個 JVM 進程中的一個線程「精子」可以訪問被保護的資源「卵子」。
元寶山ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！
Redis 分布式鎖這個話題似乎爛大街了，不管你是面試還是工作，隨處可見，「碼哥」為啥還要寫呢?
因為網(wǎng)上 99.99% 的文章都沒有真正的把分布式鎖說清楚，存在很多 bug。
今日，「碼哥」就跟大家深入分布式鎖的 G 點，系統(tǒng)的做一個寫好代碼掌握技巧的真男人。
在進入「高潮」之前，以下問題就當做「前戲」去思考，你能回答多少?
- 什么時候需要分布式鎖?
- 加、解鎖的代碼位置有講究么?
- 如何避免出現(xiàn)死鎖
- 超時時間設置多少合適呢?
- 如何避免鎖被其他線程釋放
- 如何實現(xiàn)重入鎖?
- 主從架構會帶來什么安全問題?
- 什么是 Redlock
- ……
為何需要分布式鎖?
碼哥，說個通俗的例子講解下什么時候需要分布式鎖呢?
精子噴射那一刻，億級流量沖向卵子，只有一個精子能獲得與卵子結合的幸運。
造物主為了保證只有一個「精子」能獲得「卵子」的寵幸，當有一個精子進入后，卵子的外殼就會發(fā)生變化，將通道關閉把其余的精子阻擋在外。
億級別的精子就好比「并發(fā)」流量;
卵子就好比是共享資源;
卵子外殼只允許一個精子進入的特殊蛋白就是一把鎖。
而多節(jié)點構成的集群，就會有多個 JVM 進程，我們獲得同樣的效果就需要有一個中間人協(xié)調，只允許一個 JVM 中的一個線程獲得操作共享資源的資格。
分布式鎖就是用來控制同一時刻，只有一個 JVM 進程中的一個線程「精子」可以訪問被保護的資源「卵子」。
「每一個生命，都是億級選手中的佼佼者」，加油。
分布式鎖入門
分布式鎖應該滿足哪些特性?
- 互斥：在任何給定時刻，只有一個客戶端可以持有鎖;
- 無死鎖：任何時刻都有可能獲得鎖，即使獲取鎖的客戶端崩潰;
- 容錯：只要大多數(shù) Redis的節(jié)點都已經(jīng)啟動，客戶端就可以獲取和釋放鎖。
碼哥，我可以使用 SETNX key value 命令是實現(xiàn)「互斥」特性。
這個命令來自于SET if Not eXists的縮寫，意思是：如果 key 不存在，則設置 value 給這個key，否則啥都不做。
命令的返回值：
- 1：設置成功;
- 0：key 沒有設置成功。
如下場景：
敲代碼一天累了，想去放松按摩下肩頸。
168 號技師最搶手，大家喜歡點，所以并發(fā)量大，需要分布式鎖控制。
同一時刻只允許一個「客戶」預約 168 技師。
肖彩機申請 168 技師成功：
- > SETNX lock:168 1
- (integer) 1 # 獲取 168 技師成功
謝霸哥后面到，申請失敗：
- > SETNX lock 2
- (integer) 0 # 客戶謝霸哥 2 獲取失敗
此刻，申請成功的客戶就可以享受 168 技師的肩頸放松服務「共享資源」。
享受結束后，要及時釋放鎖，給后來者享受 168 技師的服務機會。
肖彩機，碼哥考考你如何釋放鎖呢?
很簡單，使用 DEL 刪除這個 key 就行。
- > DEL lock:168
- (integer) 1
碼哥，你見過「龍」么?我見過，因為我被一條龍服務過。
肖彩機，事情可沒這么簡單。
這個方案存在一個存在造成「死鎖」的問題，造成該問題的場景如下：
在按摩過程中突然收到線上報警，提起褲子就跑去公司了，沒及時執(zhí)行 DEL 釋放鎖(客戶端處理業(yè)務異常，無法正確釋放鎖);
按摩過程中心肌梗塞嗝屁了，無法執(zhí)行 DEL指令。
這樣，這個鎖就會一直占用，其他客戶就「再也沒有」機會獲取 168 技師服務了。
如何避免死鎖
碼哥，我可以在獲取鎖成功的時候設置一個「超時時間」
比如設定按摩服務一次 60 分鐘，那么在給這個 key 加鎖的時候設置 60 分鐘過期即可：
- > SETNX lock:168 1 // 獲取鎖
- (integer) 1
- > EXPIRE lock:168 60 // 60s 自動刪除
- (integer) 1
這樣，到點后鎖自動釋放，其他客戶就可以繼續(xù)享受 168 技師按摩服務了。
誰要這么寫，就糟透了。
「加鎖」、「設置超時」是兩個命令，他們不是原子操作。
如果出現(xiàn)只執(zhí)行了第一條，第二條沒機會執(zhí)行就會出現(xiàn)「超時時間」設置失敗，依然出現(xiàn)死鎖。
比如以下場景導致無法執(zhí)行第二條指令：
Redis 異常宕機;
客戶端異常崩潰;
碼哥，那咋辦，我想被一條龍服務，不能出現(xiàn)死鎖啊。
Redis 2.6.12 之后，拓展了 SET 命令的參數(shù)，滿足了當 key 不存在則設置 value，同時設置超時時間的語義，并且滿足原子性。
- SET resource_name random_value NX PX 30000
NX：表示只有 resource_name 不存在的時候才能 SET 成功，從而保證只有一個客戶端可以獲得鎖;
PX 30000：表示這個鎖有一個 30 秒自動過期時間。
執(zhí)行時間超過鎖的過期時間
這樣我能穩(wěn)妥的享受一條龍服務了么?
No，還有一種場景會導致釋放別人的鎖：
- 客戶 1 獲取鎖成功并設置 30 秒超時;
- 客戶 1 因為一些原因導致執(zhí)行很慢(網(wǎng)絡問題、發(fā)生 FullGC……)，過了 30 秒依然沒執(zhí)行完，但是鎖過期「自動釋放了」;
- 客戶 2 申請加鎖成功;
- 客戶 1 執(zhí)行完成，執(zhí)行 DEL 釋放鎖指令，這個時候就把 客戶 2 的鎖給釋放了。
有兩個關鍵問題需要解決：
- 如何合理設置過期時間?
- 如何避免刪除別人持有的鎖。
正確設置鎖超時
鎖的超時時間怎么計算合適呢?
這個時間不能瞎寫，一般要根據(jù)在測試環(huán)境多次測試，然后壓測多輪之后，比如計算出平均執(zhí)行時間 200 ms。
那么鎖的超時時間就放大為平均執(zhí)行時間的 3~5 倍。
為啥要放大呢?
因為如果鎖的操作邏輯中有網(wǎng)絡 IO 操作、JVM FullGC 等，線上的網(wǎng)絡不會總一帆風順，我們要給網(wǎng)絡抖動留有緩沖時間。
那我設置更大一點，比如設置 1 小時不是更安全?
不要鉆牛角，多大算大?
設置時間過長，一旦發(fā)生宕機重啟，就意味著 1 小時內，分布式鎖的服務全部節(jié)點不可用。
你要讓運維手動刪除這個鎖么?
只要運維真的不會打你。
有沒有完美的方案呢?不管時間怎么設置都不大合適。
我們可以讓獲得鎖的線程開啟一個守護線程，用來給快要過期的鎖「續(xù)航」。
加鎖的時候設置一個過期時間，同時客戶端開啟一個「守護線程」，定時去檢測這個鎖的失效時間。
如果快要過期，但是業(yè)務邏輯還沒執(zhí)行完成，自動對這個鎖進行續(xù)期，重新設置過期時間。
這個道理行得通，可我寫不出。
別慌，已經(jīng)有一個庫把這些工作都封裝好了他叫Redisson。
Redisson 是一個 Java 語言實現(xiàn)的 Redis SDK 客戶端，在使用分布式鎖時，它就采用了「自動續(xù)期」的方案來避免鎖過期，這個守護線程我們一般也把它叫做「看門狗」線程。
關于 Redisson 的使用與原理分析由于篇幅有限，大家可關注「碼哥字節(jié)」且聽下回分解。
避免釋放別人的鎖
出現(xiàn)釋放別人鎖的關鍵在于「無腦執(zhí)行」DEL指令，所以我們要想辦法檢查下這個鎖是不是自己加的。
解鈴還須系鈴人
碼哥，我在加鎖的時候設置一個「唯一標識」作為 value 代表加鎖的客戶端。
在釋放鎖的時候，客戶端將自己的「唯一標識」與鎖上的「標識」比較是否相等，匹配上則刪除，否則沒有權利釋放鎖。
偽代碼如下：
- // 比對 value 與 唯一標識
- if (redis.get("lock:168").equals(uuid)){
- redis.del("lock:168"); //比對成功則刪除
- }
有沒有想過，這是 GET + DEL 指令組合而成的，這里又會涉及到原子性問題。
復現(xiàn)下情況：
- 客戶端 1 第一步對比成功后，第二步還沒來得及執(zhí)行，這時候鎖到期了。
- 客戶端 2 獲取鎖成功，將自己的 「uuid」設置進去。
- 這時候客戶端 1 執(zhí)行第二步進行釋放鎖，這肯定是錯誤的。
我們是追求極致的男人，所以這里通過 Lua 腳本來實現(xiàn)，這樣判斷和刪除的過程就是原子操作了。
- if redis.call("get",KEYS[1]) == ARGV[1] then
- return redis.call("del",KEYS[1])
- else
- return 0
- end
一路優(yōu)化下來，方案似乎比較「嚴謹」了，抽象出對應的模型如下。
通過 SET lock_resource_name $unique_id NX PX $expire_time，同時啟動守護線程為快要過期單還沒執(zhí)行完畢的客戶端的鎖續(xù)命;
客戶端執(zhí)行業(yè)務邏輯操作共享資源;
通過 Lua 腳本釋放鎖，先 get 判斷鎖是否是自己加的，再執(zhí)行 DEL。
加解鎖代碼位置有講究
根據(jù)前面的分析，我們已經(jīng)有了一個「相對嚴謹」的分布式鎖了。
于是「謝霸哥」就寫了如下代碼將分布式鎖運用到項目中，以下是偽代碼邏輯：
- public void doSomething() {
- try {
- redisLock.lock(); // 上鎖
- // 處理業(yè)務
- redisLock.unlock(); // 釋放鎖
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
一旦執(zhí)行業(yè)務邏輯過程中拋出異常，程序就無法走下一步釋放鎖的流程。
所以釋放鎖的代碼一定要放在 finally{} 塊中。
加鎖的位置也有問題，如果執(zhí)行 redisLock.lock() 加鎖異常，那么就會執(zhí)行 finally{} 代碼塊指令執(zhí)行解鎖，這個時候鎖并沒有申請成功。
所以 redisLock.lock();應該放在 try 外面。
綜上所述，正確代碼位置如下 ：
- public void doSomething() {
- // 上鎖
- redisLock.lock();
- try {
- // 處理業(yè)務
- ...
- } catch (Exception e) {
- e.printStackTrace();
- } finally {
- // 釋放鎖
- redisLock.unlock();
- }
- }
實現(xiàn)可重入鎖
可重入鎖要如何實現(xiàn)呢?重入之后，超時時間如何設置呢?
當一個線程執(zhí)行一段代碼成功獲取鎖之后，繼續(xù)執(zhí)行時，又遇到加鎖的代碼，可重入性就就保證線程能繼續(xù)執(zhí)行，而不可重入就是需要等待鎖釋放之后，再次獲取鎖成功，才能繼續(xù)往下執(zhí)行。
用一段代碼解釋可重入：
- public synchronized void a() {
- b();
- }
- public synchronized void b() {
- // pass
- }
假設 X 線程在 a 方法獲取鎖之后，繼續(xù)執(zhí)行 b 方法，如果此時不可重入，線程就必須等待鎖釋放，再次爭搶鎖。
鎖明明是被 X 線程擁有，卻還需要等待自己釋放鎖，然后再去搶鎖，這看起來就很奇怪，我釋放我自己~
Redis Hash 可重入鎖
Redisson 類庫就是通過 Redis Hash 來實現(xiàn)可重入鎖，未來碼哥會專門寫一篇關于 Redisson 的使用與原理的文章……
當線程擁有鎖之后，往后再遇到加鎖方法，直接將加鎖次數(shù)加 1，然后再執(zhí)行方法邏輯。
退出加鎖方法之后，加鎖次數(shù)再減 1，當加鎖次數(shù)為 0 時，鎖才被真正的釋放。
可以看到可重入鎖最大特性就是計數(shù)，計算加鎖的次數(shù)。
所以當可重入鎖需要在分布式環(huán)境實現(xiàn)時，我們也就需要統(tǒng)計加鎖次數(shù)。
加鎖邏輯
我們可以使用 Redis hash 結構實現(xiàn)，key 表示被鎖的共享資源， hash 結構的 fieldKey 的 value 則保存加鎖的次數(shù)。
通過 Lua 腳本實現(xiàn)原子性，假設 KEYS1 = 「lock」, ARGV「1000，uuid」：
- ---- 1 代表 true
- ---- 0 代表 false
- if (redis.call('exists', KEYS[1]) == 0) then
- redis.call('hincrby', KEYS[1], ARGV[2], 1);
- redis.call('pexpire', KEYS[1], ARGV[1]);
- return 1;
- end ;
- if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
- redis.call('hincrby', KEYS[1], ARGV[2], 1);
- redis.call('pexpire', KEYS[1], ARGV[1]);
- return 1;
- end ;
- return 0;
加鎖代碼首先使用 Redis exists 命令判斷當前 lock 這個鎖是否存在。
如果鎖不存在的話，直接使用 hincrby創(chuàng)建一個鍵為 lock hash 表，并且為 Hash 表中鍵為 uuid 初始化為 0，然后再次加 1，最后再設置過期時間。
如果當前鎖存在，則使用 hexists判斷當前 lock 對應的 hash 表中是否存在 uuid 這個鍵，如果存在，再次使用 hincrby 加 1，最后再次設置過期時間。
最后如果上述兩個邏輯都不符合，直接返回。
解鎖邏輯
- -- 判斷 hash set 可重入 key 的值是否等于 0
- -- 如果為 0 代表 該可重入 key 不存在
- if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then
- return nil;
- end ;
- -- 計算當前可重入次數(shù)
- local counter = redis.call('hincrby', KEYS[1], ARGV[1], -1);
- -- 小于等于 0 代表可以解鎖
- if (counter > 0) then
- return 0;
- else
- redis.call('del', KEYS[1]);
- return 1;
- end ;
- return nil;
首先使用 hexists 判斷 Redis Hash 表是否存給定的域。
如果 lock 對應 Hash 表不存在，或者 Hash 表不存在 uuid 這個 key，直接返回 nil。
若存在的情況下，代表當前鎖被其持有，首先使用 hincrby使可重入次數(shù)減 1 ，然后判斷計算之后可重入次數(shù)，若小于等于 0，則使用 del 刪除這把鎖。
解鎖代碼執(zhí)行方式與加鎖類似，只不過解鎖的執(zhí)行結果返回類型使用 Long。這里之所以沒有跟加鎖一樣使用 Boolean ,這是因為解鎖 lua 腳本中，三個返回值含義如下：
- 1 代表解鎖成功，鎖被釋放
- 0 代表可重入次數(shù)被減 1
- null 代表其他線程嘗試解鎖，解鎖失敗
主從架構帶來的問題
碼哥，到這里分布式鎖「很完美了」吧，沒想到分布式鎖這么多門道。
路還很遠，之前分析的場景都是，鎖在「單個」Redis 實例中可能產(chǎn)生的問題，并沒有涉及到 Redis 的部署架構細節(jié)。
我們通常使用「Cluster 集群」或者「哨兵集群」的模式部署保證高可用。
這兩個模式都是基于「主從架構數(shù)據(jù)同步復制」實現(xiàn)的數(shù)據(jù)同步，而 Redis 的主從復制默認是異步的。
我們試想下如下場景會發(fā)生什么問題：
如果客戶端 1 剛往 master 節(jié)點寫入一個分布式鎖，此時這個指令還沒來得及同步到 slave 節(jié)點。
此時，master 節(jié)點宕機，其中一個 slave 被選舉為新 master，這時候新 master 是沒有客戶端 1 寫入的鎖，鎖丟失了。
此刻，客戶端 2 線程來獲取鎖，就成功了。
雖然這個概率極低，但是我們必須得承認這個風險的存在。
Redis 的作者提出了一種解決方案，叫 Redlock(紅鎖)
Redis 的作者為了統(tǒng)一分布式鎖的標準，搞了一個 Redlock，算是 Redis 官方對于實現(xiàn)分布式鎖的指導規(guī)范，https://redis.io/topics/distlock，但是這個 Redlock 也被國外的一些分布式專家給噴了。
因為它也不完美，有“漏洞”。
什么是 Redlock
紅鎖是不是這個?
泡面吃多了你，Redlock 紅鎖是為了解決主從架構中鎖丟失而提出的一種算法。
Redlock 的方案基于 2 個前提：
- 不需要部署從庫和哨兵實例，只部署主庫
- 但主庫要部署多個，官方推薦至少 5 個實例，這樣可以保證他們不會同時宕機。
也就是說，想用使用 Redlock，你至少要部署 5 個 Redis 實例，而且都是主庫，它們之間沒有任何關系，都是一個個孤立的實例。
一個客戶端要獲取鎖有 5 個步驟：
- 客戶端獲取當前時間 T1(毫秒級別);
- 使用相同的 key和 value順序嘗試從 N個 Redis實例上獲取鎖。
- 每個請求都設置一個超時時間(毫秒級別)，該超時時間要遠小于鎖的有效時間，這樣便于快速嘗試與下一個實例發(fā)送請求。
- 比如鎖的自動釋放時間 10s，則請求的超時時間可以設置 5~50 毫秒內，這樣可以防止客戶端長時間阻塞。
- 客戶端獲取當前時間 T2 并減去步驟 1 的 T1 來計算出獲取鎖所用的時間(T3 = T2 -T1)。當且僅當客戶端在大多數(shù)實例(N/2 + 1)獲取成功，且獲取鎖所用的總時間 T3 小于鎖的有效時間，才認為加鎖成功，否則加鎖失敗。
- 如果第 3 步加鎖成功，則執(zhí)行業(yè)務邏輯操作共享資源，key 的真正有效時間等于有效時間減去獲取鎖所使用的時間(步驟 3 計算的結果)。
- 如果因為某些原因，獲取鎖失敗(沒有在至少 N/2+1 個 Redis 實例取到鎖或者取鎖時間已經(jīng)超過了有效時間)，客戶端應該在所有的 Redis 實例上進行解鎖(即便某些 Redis 實例根本就沒有加鎖成功)。
為什么要部署多個實例并加鎖呢?
本質是為了高可用和容錯，即使部分實例宕機，大多數(shù)實例加鎖成功，整個分布式鎖服務依然可用。
為啥在第三步要計算加鎖的累計時間?
因為多個節(jié)點加鎖，耗時可能會比較長，網(wǎng)絡中可能存在丟包、超時等現(xiàn)象。
即使大多數(shù)節(jié)點獲取鎖成功，假如獲取鎖的總時間已經(jīng)超過鎖的有效時間，這個鎖已經(jīng)沒有意義了。
為什么釋放鎖要操作所有節(jié)點，即使有的節(jié)點加鎖未成功?
因為有可能客戶端在 Redis 實例上加鎖成功，只是客戶端讀取響應的時候失敗導致客戶端以為加鎖失敗。
為了安全的清理鎖，就需要向每個節(jié)點發(fā)送釋放鎖的請求。
Redlock 這么完美?那他解決了 Redis 主從架構節(jié)點異常宕機導致鎖丟失的問題了么?
事情可沒這么簡單，Redis 作者把這個方案提出后，受到了業(yè)界著名的分布式系統(tǒng)專家的質疑。
兩人好比神仙打架，兩人一來一回論據(jù)充足的對一個問題提出很多論斷……
由于篇幅原因，關于 兩人的爭論分析以及 Redssion 對分布式鎖的封裝以及 Redlock 的實現(xiàn)我們下期再見。
預知后事如何，且聽下回分解…
總結
完工，我建議你合上屏幕，自己在腦子里重新過一遍，每一步都在做什么，為什么要做，解決什么問題。
我們一起從頭到尾梳理了一遍 Redis 分布式鎖中的各種門道，其實很多點是不管用什么做分布式鎖都會存在的問題，重要的是思考的過程。
對于系統(tǒng)的設計，每個人的出發(fā)點都不一樣，沒有完美的架構，沒有普適的架構，但是在完美和普適能平衡的很好的架構，就是好的架構。
關于 Redlock 的爭論主要集中在如下幾點：
- Redlock 效率太差、太重，對于提升效率的場景下，使用分布式鎖，允許鎖的偶爾失效，那么使用單 Redis 節(jié)點的鎖方案就足夠了，簡單而且效率高。
- 對于正確性要求高的場景下，它是依賴于時間的，不是一個足夠強的算法。Redlock 并沒有保住正確性。
分享標題：Redis分布式鎖沒這么簡單，網(wǎng)上大多數(shù)都有bug
當前網(wǎng)址：http://www.5511xx.com/article/dhsgici.html
