建站
咨詢
售后
建站咨詢
新聞中心
七種方案！探討Redis分布式鎖的正確使用姿勢
作者：撿田螺的小男孩 2021-03-07 16:11:26
存儲
存儲軟件
分布式
Redis 日常開發(fā)中，秒殺下單、搶紅包等等業(yè)務場景，都需要用到分布式鎖。而Redis非常適合作為分布式鎖使用。本文將分七個方案展開，跟大家探討Redis分布式鎖的正確使用方式。
前言
日常開發(fā)中，秒殺下單、搶紅包等等業(yè)務場景，都需要用到分布式鎖。而Redis非常適合作為分布式鎖使用。本文將分七個方案展開，跟大家探討Redis分布式鎖的正確使用方式。如果有不正確的地方，歡迎大家指出哈，一起學習一起進步。
公眾號：「撿田螺的小男孩」
- 什么是分布式鎖
- 方案一：SETNX + EXPIRE
- 方案二：SETNX + value值是(系統(tǒng)時間+過期時間)
- 方案三：使用Lua腳本(包含SETNX + EXPIRE兩條指令)
- 方案四：SET的擴展命令(SET EX PX NX)
- 方案五：SET EX PX NX + 校驗唯一隨機值,再釋放鎖
- 方案六: 開源框架~Redisson
- 方案七：多機實現(xiàn)的分布式鎖Redlock
什么是分布式鎖
分布式鎖其實就是，控制分布式系統(tǒng)不同進程共同訪問共享資源的一種鎖的實現(xiàn)。如果不同的系統(tǒng)或同一個系統(tǒng)的不同主機之間共享了某個臨界資源，往往需要互斥來防止彼此干擾，以保證一致性。
我們先來看下，一把靠譜的分布式鎖應該有哪些特征：
- 「互斥性」: 任意時刻，只有一個客戶端能持有鎖。
- 「鎖超時釋放」：持有鎖超時，可以釋放，防止不必要的資源浪費，也可以防止死鎖。
- 「可重入性」:一個線程如果獲取了鎖之后,可以再次對其請求加鎖。
- 「高性能和高可用」：加鎖和解鎖需要開銷盡可能低，同時也要保證高可用，避免分布式鎖失效。
- 「安全性」：鎖只能被持有的客戶端刪除，不能被其他客戶端刪除
Redis分布式鎖方案一：SETNX + EXPIRE
提到Redis的分布式鎖，很多小伙伴馬上就會想到setnx+ expire命令。即先用setnx來搶鎖，如果搶到之后，再用expire給鎖設置一個過期時間，防止鎖忘記了釋放。
SETNX 是SET IF NOT EXISTS的簡寫.日常命令格式是SETNX key value，如果 key不存在，則SETNX成功返回1，如果這個key已經(jīng)存在了，則返回0。
假設某電商網(wǎng)站的某商品做秒殺活動，key可以設置為key_resource_id,value設置任意值，偽代碼如下：
- if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加鎖
- expire（key_resource_id，100）; //設置過期時間
- try {
- do something //業(yè)務請求
- }catch(){
- }
- finally {
- jedis.del(key_resource_id); //釋放鎖
- }
- }
但是這個方案中，setnx和expire兩個命令分開了，「不是原子操作」。如果執(zhí)行完setnx加鎖，正要執(zhí)行expire設置過期時間時，進程crash或者要重啟維護了，那么這個鎖就“長生不老”了，「別的線程永遠獲取不到鎖啦」。
Redis分布式鎖方案二：SETNX + value值是(系統(tǒng)時間+過期時間)
為了解決方案一，「發(fā)生異常鎖得不到釋放的場景」，有小伙伴認為，可以把過期時間放到setnx的value值里面。如果加鎖失敗，再拿出value值校驗一下即可。加鎖代碼如下：
- long expires = System.currentTimeMillis() + expireTime; //系統(tǒng)時間+設置的過期時間
- String expiresStr = String.valueOf(expires);
- // 如果當前鎖不存在，返回加鎖成功
- if (jedis.setnx(key_resource_id, expiresStr) == 1) {
- return true;
- }
- // 如果鎖已經(jīng)存在，獲取鎖的過期時間
- String currentValueStr = jedis.get(key_resource_id);
- // 如果獲取到的過期時間，小于系統(tǒng)當前時間，表示已經(jīng)過期
- if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
- // 鎖已過期，獲取上一個鎖的過期時間，并設置現(xiàn)在鎖的過期時間（不了解redis的getSet命令的小伙伴，可以去官網(wǎng)看下哈）
- String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
- if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
- // 考慮多線程并發(fā)的情況，只有一個線程的設置值和當前值相同，它才可以加鎖
- return true;
- }
- }
- //其他情況，均返回加鎖失敗
- return false;
- }
這個方案的優(yōu)點是，巧妙移除expire單獨設置過期時間的操作，把「過期時間放到setnx的value值」里面來。解決了方案一發(fā)生異常，鎖得不到釋放的問題。但是這個方案還有別的缺點：
- 過期時間是客戶端自己生成的(System.currentTimeMillis()是當前系統(tǒng)的時間)，必須要求分布式環(huán)境下，每個客戶端的時間必須同步。
- 如果鎖過期的時候，并發(fā)多個客戶端同時請求過來，都執(zhí)行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指令擴展參數(shù)!(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 //業(yè)務處理
- }catch(){
- }
- finally {
- jedis.del(key_resource_id); //釋放鎖
- }
- }
但是呢，這個方案還是可能存在問題：
- 問題一：「鎖過期釋放了，業(yè)務還沒執(zhí)行完」。假設線程a獲取鎖成功，一直在執(zhí)行臨界區(qū)的代碼。但是100s過去后，它還沒執(zhí)行完。但是，這時候鎖已經(jīng)過期了，此時線程b又請求過來。顯然線程b就可以獲得鎖成功，也開始執(zhí)行臨界區(qū)的代碼。那么問題就來了，臨界區(qū)的業(yè)務代碼都不是嚴格串行執(zhí)行的啦。
- 問題二：「鎖被別的線程誤刪」。假設線程a執(zhí)行完后，去釋放鎖。但是它不知道當前的鎖可能是線程b持有的(線程a去釋放鎖時，有可能過期時間已經(jīng)到了，此時線程b進來占有了鎖)。那線程a就把線程b的鎖釋放掉了，但是線程b臨界區(qū)業(yè)務代碼可能都還沒執(zhí)行完呢。
方案五：SET EX PX NX + 校驗唯一隨機值,再刪除
既然鎖可能被別的線程誤刪，那我們給value值設置一個標記當前線程唯一的隨機數(shù)，在刪除的時候，校驗一下，不就OK了嘛。偽代碼如下：
- if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加鎖
- try {
- do something //業(yè)務處理
- }catch(){
- }
- finally {
- //判斷是不是當前線程加的鎖,是才釋放
- if (uni_request_id.equals(jedis.get(key_resource_id))) {
- jedis.del(lockKey); //釋放鎖
- }
- }
- }
在這里，「判斷是不是當前線程加的鎖」和「釋放鎖」不是一個原子操作。如果調(diào)用jedis.del()釋放鎖的時候，可能這把鎖已經(jīng)不屬于當前客戶端，會解除他人加的鎖。
為了更嚴謹，一般也是用lua腳本代替。lua腳本如下：
- if redis.call('get',KEYS[1]) == ARGV[1] then
- return redis.call('del',KEYS[1])
- else
- return 0
- end;
Redis分布式鎖方案六：Redisson框架
方案五還是可能存在「鎖過期釋放，業(yè)務沒執(zhí)行完」的問題。有些小伙伴認為，稍微把鎖過期時間設置長一些就可以啦。其實我們設想一下，是否可以給獲得鎖的線程，開啟一個定時守護線程，每隔一段時間檢查鎖是否還存在，存在則對鎖的過期時間延長，防止鎖過期提前釋放。
當前開源框架Redisson解決了這個問題。我們一起來看下Redisson底層原理圖吧：
只要線程一加鎖成功，就會啟動一個watch dog看門狗，它是一個后臺線程，會每隔10秒檢查一下，如果線程1還持有鎖，那么就會不斷的延長鎖key的生存時間。因此，Redisson就是使用Redisson解決了「鎖過期釋放，業(yè)務沒執(zhí)行完」問題。
Redis分布式鎖方案七：多機實現(xiàn)的分布式鎖Redlock+Redisson
前面六種方案都只是基于單機版的討論，還不是很完美。其實Redis一般都是集群部署的：
如果線程一在Redis的master節(jié)點上拿到了鎖，但是加鎖的key還沒同步到slave節(jié)點。恰好這時，master節(jié)點發(fā)生故障，一個slave節(jié)點就會升級為master節(jié)點。線程二就可以獲取同個key的鎖啦，但線程一也已經(jīng)拿到鎖了，鎖的安全性就沒了。
為了解決這個問題，Redis作者 antirez提出一種高級的分布式鎖算法：Redlock。Redlock核心思想是這樣的：
搞多個Redis master部署，以保證它們不會同時宕掉。并且這些master節(jié)點是完全相互獨立的，相互之間不存在數(shù)據(jù)同步。同時，需要確保在這多個master實例上，是與在Redis單實例，使用相同方法來獲取和釋放鎖。
我們假設當前有5個Redis master節(jié)點，在5臺服務器上面運行這些Redis實例。
RedLock的實現(xiàn)步驟:如下
1.獲取當前時間，以毫秒為單位。
2.按順序向5個master節(jié)點請求加鎖?？蛻舳嗽O置網(wǎng)絡連接和響應超時時間，并且超時時間要小于鎖的失效時間。(假設鎖自動失效時間為10秒，則超時時間一般在5-50毫秒之間,我們就假設超時時間是50ms吧)。如果超時，跳過該master節(jié)點，盡快去嘗試下一個master節(jié)點。
3.客戶端使用當前時間減去開始獲取鎖時間(即步驟1記錄的時間)，得到獲取鎖使用的時間。當且僅當超過一半(N/2+1，這里是5/2+1=3個節(jié)點)的Redis master節(jié)點都獲得鎖，并且使用的時間小于鎖失效時間時，鎖才算獲取成功。(如上圖，10s> 30ms+40ms+50ms+4m0s+50ms)
如果取到了鎖，key的真正有效時間就變啦，需要減去獲取鎖所使用的時間。
如果獲取鎖失敗(沒有在至少N/2+1個master實例取到鎖，有或者獲取鎖時間已經(jīng)超過了有效時間)，客戶端要在所有的master節(jié)點上解鎖(即便有些master節(jié)點根本就沒有加鎖成功，也需要解鎖，以防止有些漏網(wǎng)之魚)。
簡化下步驟就是：
- 按順序向5個master節(jié)點請求加鎖
- 根據(jù)設置的超時時間來判斷，是不是要跳過該master節(jié)點。
- 如果大于等于3個節(jié)點加鎖成功，并且使用的時間小于鎖的有效期，即可認定加鎖成功啦。
- 如果獲取鎖失敗，解鎖!
Redisson實現(xiàn)了redLock版本的鎖，有興趣的小伙伴，可以去了解一下哈~
參考與感謝
redis系列：分布式鎖[1]
淺析 Redis 分布式鎖解決方案[2]
細說Redis分布式鎖??[3]
Redlock：Redis分布式鎖最牛逼的實現(xiàn)
本文轉(zhuǎn)載自微信公眾號「撿田螺的小男孩」，作者撿田螺的小男孩。轉(zhuǎn)載本文請聯(lián)系撿田螺的小男孩公眾號。
新聞名稱：七種方案！探討Redis分布式鎖的正確使用姿勢
分享網(wǎng)址：http://www.5511xx.com/article/djechss.html
