### 前言 日常開發中，秒殺下單、搶紅包等等業務場景，都需要用到分散式鎖。而Redis非常適合作為分散式鎖使用。本文將分七個方案展開，跟大家探討Redis分散式鎖的正確使用方式。如果有不正確的地方，歡迎大家指出哈，一起學習一起進步。 公眾號：**撿田螺的小男孩** - 什麼是分散式鎖 - 方案一：SETNX + EXPIRE - 方案二：SETNX + value值是（系統時間+過期時間） - 方案三：使用Lua指令碼(包含SETNX + EXPIRE兩條指令) - 方案四：SET的擴充套件命令（SET EX PX NX） - 方案五：SET EX PX NX + 校驗唯一隨機值,再刪除釋放 - 方案六: 開源框架:Redisson - 方案七：多機實現的分散式鎖Redlock ### 什麼是分散式鎖 > 分散式鎖其實就是，控制分散式系統不同程序共同訪問共享資源的一種鎖的實現。如果不同的系統或同一個系統的不同主機之間共享了某個臨界資源，往往需要互斥來防止彼此干擾，以保證一致性。 我們先來看下，一把靠譜的分散式鎖應該有哪些特徵：  - **互斥性**: 任意時刻，只有一個客戶端能持有鎖。 - **鎖超時釋放**：持有鎖超時，可以釋放，防止不必要的資源浪費，也可以防止死鎖。 - **可重入性**:一個執行緒如果獲取了鎖之後,可以再次對其請求加鎖。 - **高效能和高可用**：加鎖和解鎖需要開銷儘可能低，同時也要保證高可用，避免分散式鎖失效。 - **安全性**：鎖只能被持有的客戶端刪除，不能被其他客戶端刪除 ### Redis分散式鎖方案一：SETNX + EXPIRE 提到Redis的分散式鎖，很多小夥伴馬上就會想到```setnx```+ ```expire```命令。即先用```setnx```來搶鎖，如果搶到之後，再用```expire```給鎖設定一個過期時間，防止鎖忘記了釋放。 > SETNX 是SET IF NOT EXISTS的簡寫.日常命令格式是SETNX key value，如果 key不存在，則SETNX成功返回1，如果這個key已經存在了，則返回0。 假設某電商網站的某商品做秒殺活動，key可以設定為key_resource_id,value設定任意值，虛擬碼如下： ``` if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加鎖 expire（key_resource_id，100）; //設定過期時間 try { do something //業務請求 }catch(){ 　　} 　　finally { jedis.del(key_resource_id); //釋放鎖 } } ``` 但是這個方案中，```setnx```和```expire```兩個命令分開了，**不是原子操作**。如果執行完```setnx```加鎖，正要執行```expire```設定過期時間時，程序crash或者要重啟維護了，那麼這個鎖就“長生不老”了，**別的執行緒永遠獲取不到鎖啦**。 ### Redis分散式鎖方案二：SETNX + value值是(系統時間+過期時間) 為了解決方案一，**發生異常鎖得不到釋放的場景**，有小夥伴認為，可以把過期時間放到```setnx```的value值裡面。如果加鎖失敗，再拿出value值校驗一下即可。加鎖程式碼如下： ``` long expires = System.currentTimeMillis() + expireTime; //系統時間+設定的過期時間 String expiresStr = String.valueOf(expires); // 如果當前鎖不存在，返回加鎖成功 if (jedis.setnx(key_resource_id, expiresStr) == 1) { return true; } // 如果鎖已經存在，獲取鎖的過期時間 String currentValueStr = jedis.get(key_resource_id); // 如果獲取到的過期時間，小於系統當前時間，表示已經過期 if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) { // 鎖已過期，獲取上一個鎖的過期時間，並設定現在鎖的過期時間（不瞭解redis的getSet命令的小夥伴，可以去官網看下哈） String oldValueStr = jedis.getSet(key_resource_id, expiresStr); if (oldValueStr != null && oldValueStr.equals(currentValueStr)) { // 考慮多執行緒併發的情況，只有一個執行緒的設定值和當前值相同，它才可以加鎖 return true; } } //其他情況，均返回加鎖失敗 return false; } ``` 這個方案的優點是，巧妙移除```expire```單獨設定過期時間的操作，把**過期時間放到setnx的value值**裡面來。解決了方案一發生異常，鎖得不到釋放的問題。但是這個方案還有別的缺點： > - 過期時間是客戶端自己生成的（System.currentTimeMillis()是當前系統的時間），必須要求分散式環境下，每個客戶端的時間必須同步。 > - 如果鎖過期的時候，併發多個客戶端同時請求過來，都執行jedis.getSet()，最終只能有一個客戶端加鎖成功，但是該客戶端鎖的過期時間，可能被別的客戶端覆蓋 > - 該鎖沒有儲存持有者的唯一標識，可能被別的客戶端釋放/解鎖。 ### Redis分散式鎖方案三：使用Lua指令碼(包含SETNX + EXPIRE兩條指令) 實際上，我們還可以使用Lua指令碼來保證原子性（包含setnx和expire兩條指令），lua指令碼如下： ``` if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then redis.call('expire',KEYS[1],ARGV[2]) else return 0 end; ``` 加鎖程式碼如下： ``` String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" + " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end"; Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values)); //判斷是否成功 return result.equals(1L); ``` 這個方案，跟方案二對比，你覺得哪個更好呢？ ### Redis分散式鎖方案方案四：SET的擴充套件命令（SET EX PX NX） 除了使用，使用Lua指令碼，保證```SETNX + EXPIRE```兩條指令的原子性，我們還可以巧用Redis的SET指令擴充套件引數！（```SET key value[EX seconds][PX milliseconds][NX|XX]```），它也是原子性的！ > SET key value[EX seconds][PX milliseconds][NX|XX] > - NX :表示key不存在的時候，才能set成功，也即保證只有第一個客戶端請求才能獲得鎖，而其他客戶端請求只能等其釋放鎖，才能獲取。 > - EX seconds :設定key的過期時間，時間單位是秒。 > - PX milliseconds: 設定key的過期時間，單位為毫秒 > - XX: 僅當key存在時設定值 虛擬碼demo如下： ``` if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加鎖 try { do something //業務處理 }catch(){ 　　} 　　finally { jedis.del(key_resource_id); //釋放鎖 } } ``` 但是呢，這個方案還是可能存在問題： - 問題一：**鎖過期釋放了，業務還沒執行完**。假設執行緒a獲取鎖成功，一直在執行臨界區的程式碼。但是100s過去後，它還沒執行完。但是，這時候鎖已經過期了，此時執行緒b又請求過來。顯然執行緒b就可以獲得鎖成功，也開始執行臨界區的程式碼。那麼問題就來了，臨界區的業務程式碼都不是嚴格序列執行的啦。 - 問題二：**鎖被別的執行緒誤刪**。假設執行緒a執行完後，去釋放鎖。但是它不知道當前的鎖可能是執行緒b持有的（執行緒a去釋放鎖時，有可能過期時間已經到了，此時執行緒b進來佔有了鎖）。那執行緒a就把執行緒b的鎖釋放掉了，但是執行緒b臨界區業務程式碼可能都還沒執行完呢。 ### 方案五：SET EX PX NX + 校驗唯一隨機值,再刪除 既然鎖可能被別的執行緒誤刪，那我們給value值設定一個標記當前執行緒唯一的隨機數，在刪除的時候，校驗一下，不就OK了嘛。虛擬碼如下： ``` if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加鎖 try { do something //業務處理 }catch(){ 　　} 　　finally { //判斷是不是當前執行緒加的鎖,是才釋放 if (uni_request_id.equals(jedis.get(key_resource_id))) { jedis.del(lockKey); //釋放鎖 } } } ``` 在這裡，**判斷是不是當前執行緒加的鎖**和**釋放鎖**不是一個原子操作。如果呼叫jedis.del()釋放鎖的時候，可能這把鎖已經不屬於當前客戶端，會解除他人加的鎖。  為了更嚴謹，一般也是用lua指令碼代替。lua指令碼如下： ``` if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end; ``` ### Redis分散式鎖方案六：Redisson框架 方案五還是可能存在**鎖過期釋放，業務沒執行完**的問題。有些小夥伴認為，稍微把鎖過期時間設定長一些就可以啦。其實我們設想一下，是否可以給獲得鎖的執行緒，開啟一個定時守護執行緒，每隔一段時間檢查鎖是否還存在，存在則對鎖的過期時間延長，防止鎖過期提前釋放。 當前開源框架Redisson解決了這個問題。我們一起來看下Redisson底層原理圖吧：  只要執行緒一加鎖成功，就會啟動一個```watch dog```看門狗，它是一個後臺執行緒，會每隔10秒檢查一下，如果執行緒1還持有鎖，那麼就會不斷的延長鎖key的生存時間。因此，Redisson就是使用Redisson解決了**鎖過期釋放，業務沒執行完**問題。 ### Redis分散式鎖方案七：多機實現的分散式鎖Redlock+Redisson 前面六種方案都只是基於單機版的討論，還不是很完美。其實Redis一般都是叢集部署的：  如果執行緒一在Redis的master節點上拿到了鎖，但是加鎖的key還沒同步到slave節點。恰好這時，master節點發生故障，一個slave節點就會升級為master節點。執行緒二就可以獲取同個key的鎖啦，但執行緒一也已經拿到鎖了，鎖的安全性就沒了。 為了解決這個問題，Redis作者 antirez提出一種高階的分散式鎖演算法：Redlock。Redlock核心思想是這樣的： > 搞多個Redis master部署，以保證它們不會同時宕掉。並且這些master節點是完全相互獨立的，相互之間不存在資料同步。同時，需要確保在這多個master例項上，是與在Redis單例項，使用相同方法來獲取和釋放鎖。 我們假設當前有5個Redis master節點，在5臺伺服器上面執行這些Redis例項。  RedLock的實現步驟:如下 > - 1.獲取當前時間，以毫秒為單位。 > - 2.按順序向5個master節點請求加鎖。客戶端設定網路連線和響應超時時間，並且超時時間要小於鎖的失效時間。（假設鎖自動失效時間為10秒，則超時時間一般在5-50毫秒之間,我們就假設超時時間是50ms吧）。如果超時，跳過該master節點，儘快去嘗試下一個master節點。 > - 3.客戶端使用當前時間減去開始獲取鎖時間（即步驟1記錄的時間），得到獲取鎖使用的時間。當且僅當超過一半（N/2+1，這裡是5/2+1=3個節點）的Redis master節點都獲得鎖，並且使用的時間小於鎖失效時間時，鎖才算獲取成功。（如上圖，10s> 30ms+40ms+50ms+4m0s+50ms） > - 如果取到了鎖，key的真正有效時間就變啦，需要減去獲取鎖所使用的時間。 > - 如果獲取鎖失敗（沒有在至少N/2+1個master例項取到鎖，有或者獲取鎖時間已經超過了有效時間），客戶端要在所有的master節點上解鎖（即便有些master節點根本就沒有加鎖成功，也需要解鎖，以防止有些漏網之魚）。 簡化下步驟就是： - 按順序向5個master節點請求加鎖 - 根據設定的超時時間來判斷，是不是要跳過該master節點。 - 如果大於等於三個節點加鎖成功，並且使用的時間小於鎖的有效期，即可認定加鎖成功啦。 - 獲取鎖失敗，解鎖！ Redisson實現了redLock版本的鎖，有興趣的小夥伴，可以去了解一下哈~ ### 參考與感謝 - [redis系列：分散式鎖](https://juejin.cn/post/6844903656911798285) - [淺析 Redis 分散式鎖解決方案](https://www.infoq.cn/article/dvaaj71f4fbqsxmgvdce) - [細說Redis分散式鎖