前言

日常開發(fā)中，經(jīng)常會碰到秒殺搶購等業(yè)務(wù)。為了避免并發(fā)請求造成的庫存超賣 等問題，我們一般會用到Redis分布式鎖。但是使用Redis分布式鎖，很容易踩坑哦~ 本文田螺哥將給大家分析闡述，Redis分布式鎖的10個坑~

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

1. 非原子操作（setnx + expire）

一說到實現(xiàn)Redis的分布式鎖，很多小伙伴馬上就會想到setnx+ expire命令。也就是說，先用setnx來搶鎖，如果搶到之后，再用expire給鎖設(shè)置一個過期 時間。

偽代碼如下：

if（jedis.setnx(lock_key,lock_value)==1）{//加鎖
jedis.expire(lock_key，timeout）;//設(shè)置過期時間
doBusiness//業(yè)務(wù)邏輯處理
}

這塊代碼是有坑 的，因為setnx和expire兩個命令是分開寫的，并不是原子操作！如果剛要執(zhí)行完setnx加鎖，正要執(zhí)行expire設(shè)置過期時間時，進(jìn)程crash或者要重啟維護(hù)了，那么這個鎖就“長生不老 ”了，別的線程永遠(yuǎn)獲取不到鎖啦。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

2. 被別的客戶端請求覆蓋（ setnx + value為過期時間）

為了解決：發(fā)生異常時，鎖得不到釋放的問題 。有小伙伴提出，可以把過期時間 放到setnx的value里面。如果加鎖失敗，再拿出value值和當(dāng)前系統(tǒng)時間校驗一下是否過期即可。偽代碼實現(xiàn)如下：

longexpireTime=System.currentTimeMillis()+timeout;//系統(tǒng)時間+設(shè)置的超時時間
StringexpireTimeStr=String.valueOf(expireTime);//轉(zhuǎn)化為String字符串

//如果當(dāng)前鎖不存在，返回加鎖成功
if(jedis.setnx(lock_key,expireTimeStr)==1){
returntrue;
}

//如果鎖已經(jīng)存在，獲取鎖的過期時間
StringoldExpireTimreStr=jedis.get(lock_key);

//如果獲取到的老的預(yù)期過期時間，小于系統(tǒng)當(dāng)前時間，表示已經(jīng)過期了
if(oldExpireTimreStr!=null&&Long.parseLong(oldExpireTimreStr)//鎖已過期，獲取上一個鎖的過期時間，并設(shè)置現(xiàn)在鎖的過期時間（不了解redis的getSet命令的小伙伴，可以去官網(wǎng)看下哈）
StringoldValueStr=jedis.getSet(lock_key,expireTimeStr);

if(oldValueStr!=null&&oldValueStr.equals(oldExpireTimreStr)){
//考慮多線程并發(fā)的情況，只有一個線程的設(shè)置值和當(dāng)前值相同，它才可以加鎖
returntrue;
}
}

//其他情況，均返回加鎖失敗
returnfalse;
}

這種實現(xiàn)的方案，也是有坑的：如果鎖過期的時候，并發(fā)多個客戶端同時請求過來，都執(zhí)行jedis.getSet()，最終只能有一個客戶端加鎖成功，但是該客戶端鎖的過期時間，可能被別的客戶端覆蓋 。

3. 忘記設(shè)置過期時間

之前review代碼的時候，看到這樣實現(xiàn)的分布式鎖，偽代碼 ：

try{
if(jedis.setnx(lock_key,lock_value)==1){//加鎖
doBusiness//業(yè)務(wù)邏輯處理
returntrue;//加鎖成功，處理完業(yè)務(wù)邏輯返回
}
returnfalse;//加鎖失敗
}finally{
unlock(lockKey);-//釋放鎖
}

這塊有什么問題呢？是的，忘記設(shè)置過期時間了 。如果程序在運行期間，機器突然掛了，代碼層面沒有走到finally代碼塊，即在宕機前，鎖并沒有被刪除掉，這樣的話，就沒辦法保證解鎖，所以這里需要給lockKey加一個過期時間。注意哈，使用分布式鎖，一定要設(shè)置過期時間哈 。

4. 業(yè)務(wù)處理完，忘記釋放鎖

很多小伙伴，會使用Redis的set指令擴(kuò)展參數(shù)來實現(xiàn)分布式鎖。

set指令擴(kuò)展參數(shù)：SET key value[EX seconds][PX milliseconds][NX|XX]

-NX:表示key不存在的時候，才能set成功，也即保證只有第一個客戶端請求才能獲得鎖，
而其他客戶端請求只能等其釋放鎖，才能獲取。
- EX seconds :設(shè)定key的過期時間，時間單位是秒。
-PXmilliseconds:設(shè)定key的過期時間，單位為毫秒
-XX:僅當(dāng)key存在時設(shè)置值

小伙伴會寫出如下偽代碼：

if(jedis.set(lockKey,requestId,"NX","PX",expireTime)==1){//加鎖
doBusiness//業(yè)務(wù)邏輯處理
returntrue;//加鎖成功，處理完業(yè)務(wù)邏輯返回
}
returnfalse;//加鎖失敗

這塊偽代碼，初看覺得沒啥問題，但是細(xì)想，不太對呀。因為忘記釋放鎖 了！如果每次加鎖成功，都要等到超時時間才釋放鎖 ，是會有問題的。這樣程序不高效，應(yīng)當(dāng)每次處理完業(yè)務(wù)邏輯，都要釋放鎖 。

正例如下：

try{
if(jedis.set(lockKey,requestId,"NX","PX",expireTime)==1){//加鎖
doBusiness//業(yè)務(wù)邏輯處理
returntrue;//加鎖成功，處理完業(yè)務(wù)邏輯返回
}
returnfalse;//加鎖失敗
}finally{
unlock(lockKey);-//釋放鎖
}

5. B的鎖被A給釋放了

我們來看下這塊偽代碼：

try{
if(jedis.set(lockKey,requestId,"NX","PX",expireTime)==1){//加鎖
doBusiness//業(yè)務(wù)邏輯處理
returntrue;//加鎖成功，處理完業(yè)務(wù)邏輯返回
}
returnfalse;//加鎖失敗
}finally{
unlock(lockKey);//釋放鎖
}

大家覺得會有哪些坑 呢？

假設(shè)在這樣的并發(fā)場景下：A、B兩個線程來嘗試給Redis的keylockKey加鎖，A線程先拿到鎖（假如鎖超時時間是3秒后過期）。如果線程A執(zhí)行的業(yè)務(wù)邏輯很耗時，超過了3秒還是沒有執(zhí)行完。這時候，Redis會自動釋放lockKey鎖。剛好這時，線程B過來了，它就能搶到鎖了，開始執(zhí)行它的業(yè)務(wù)邏輯，恰好這時，線程A執(zhí)行完邏輯，去釋放鎖的時候，它就把B的鎖給釋放掉了。

正確的方式應(yīng)該是，在用set擴(kuò)展參數(shù)加鎖時，放多一個這個線程請求的唯一標(biāo)記 ，比如requestId，然后釋放鎖的時候，判斷一下是不是剛剛的請求 。

try{
if(jedis.set(lockKey,requestId,"NX","PX",expireTime)==1){//加鎖
doBusiness//業(yè)務(wù)邏輯處理
returntrue;//加鎖成功，處理完業(yè)務(wù)邏輯返回
}
returnfalse;//加鎖失敗
}finally{
if(requestId.equals(jedis.get(lockKey))){//判斷一下是不是自己的requestId
unlock(lockKey);//釋放鎖
}
}

6. 釋放鎖時，不是原子性

以上的這塊代碼，還是有坑：

if(requestId.equals(jedis.get(lockKey))){//判斷一下是不是自己的requestId
unlock(lockKey);//釋放鎖
}

因為判斷是不是當(dāng)前線程加的鎖和釋放鎖不是一個原子操作 。如果調(diào)用unlock(lockKey)釋放鎖的時候，鎖已經(jīng)過期，所以這把鎖已經(jīng)可能已經(jīng)不屬于當(dāng)前客戶端，會解除他人加的鎖 。

因此，這個坑就是：判斷和刪除是兩個操作，不是原子的，有一致性問題。釋放鎖必須保證原子性，可以使用Redis+Lua腳本來完成，類似Lua腳本如下：

ifredis.call('get',KEYS[1])==ARGV[1]then
returnredis.call('del',KEYS[1])
else
return0
end;

7. 鎖過期釋放，業(yè)務(wù)沒執(zhí)行完

加鎖后，如果超時了，Redis會自動釋放清除鎖，這樣有可能業(yè)務(wù)還沒處理完，鎖就提前釋放了 。怎么辦呢？

有些小伙伴認(rèn)為，稍微把鎖過期時間設(shè)置長一些就可以啦。其實我們設(shè)想一下 ，是否可以給獲得鎖的線程，開啟一個定時守護(hù)線程，每隔一段時間檢查鎖是否還存在，存在則對鎖的過期時間延長，防止鎖過期提前釋放。

當(dāng)前開源框架Redisson解決了這個問題。我們一起來看下Redisson底層原理圖吧：

只要線程一加鎖成功，就會啟動一個watch dog看門狗，它是一個后臺線程 ，會每隔10秒檢查一下，如果線程一還持有鎖，那么就會不斷的延長鎖key的生存時間。因此，Redisson就是使用Redisson解決了鎖過期釋放，業(yè)務(wù)沒執(zhí)行完問題 。

8. Redis分布式鎖和@transactional一起使用失效

大家看下這塊偽代碼:

@Transactional
publicvoidupdateDB(intlockKey){
booleanlockFlag=redisLock.lock(lockKey);
if(!lockFlag){
thrownewRuntimeException(“請稍后再試”);
}
doBusiness//業(yè)務(wù)邏輯處理
redisLock.unlock(lockKey);
}

在事務(wù)中,使用了Redis分布式鎖.這個方法一旦執(zhí)行,事務(wù)生效，接著就Redis分布式鎖生效，代碼執(zhí)行完后,先釋放Redis分布式鎖,然后再提交事務(wù)數(shù)據(jù)，最后事務(wù)結(jié)束。在這個過程中,事務(wù)沒有提交之前,分布式鎖已經(jīng)被釋放，導(dǎo)致分布式鎖失效

這是因為:

spring的Aop，會在updateDB方法之前開啟事務(wù)，之后再加鎖，當(dāng)鎖住的代碼執(zhí)行完成后，再提交事務(wù)，因此鎖住的代碼塊執(zhí)行是在事務(wù)之內(nèi)執(zhí)行的，可以推斷在代碼塊執(zhí)行完時，事務(wù)還未提交，鎖已經(jīng)被釋放，此時其他線程拿到鎖之后進(jìn)行鎖住的代碼塊，讀取的庫存數(shù)據(jù)不是最新的。

正確的實現(xiàn)方法,可以在updateDB方法之前就上鎖 ，即還沒有開事務(wù)之前就加鎖，那么就可以保證線程的安全性.

9. 鎖可重入

前面討論的Redis分布式鎖，都是不可重入的 。

所謂的不可重入 ，就是當(dāng)前線程執(zhí)行某個方法已經(jīng)獲取了該鎖，那么在方法中嘗試再次獲取鎖時，會阻塞，不可以再次獲得鎖。同一個人拿一個鎖 ，只能拿一次不能同時拿2次。

不可重入的分布式鎖的話，是可以滿足絕大多數(shù)的業(yè)務(wù)場景 。但是有時候一些業(yè)務(wù)場景，我們還是需要可重入的分布式鎖 ，大家實現(xiàn)分布式鎖的過程中，需要注意一下 ，你當(dāng)前的業(yè)務(wù)場景是否需要可重入的分布式鎖。

Redis只要解決這兩個問題，就能實現(xiàn)重入鎖 了：

• 怎么保存當(dāng)前持有的線程
• 怎么維護(hù)加鎖次數(shù)（即重入了多少次）

實現(xiàn)一個可重入的分布式鎖，我們可以參考JDK的ReentrantLock的設(shè)計思想。實際上，可以直接使用Redisson框架，它是支持可重入鎖的。

10. Redis主從復(fù)制導(dǎo)致的坑

實現(xiàn)Redis分布式鎖的話，要注意Redis主從復(fù)制的坑 。因為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單實例，使用相同方法來獲取和釋放鎖。

我們假設(shè)當(dāng)前有5個Redis master節(jié)點，在5臺服務(wù)器上面運行這些Redis實例。

RedLock的實現(xiàn)步驟如下:

1. 獲取當(dāng)前時間，以毫秒為單位。
2. 按順序向5個master節(jié)點請求加鎖。客戶端設(shè)置網(wǎng)絡(luò)連接和響應(yīng)超時時間，并且超時時間要小于鎖的失效時間。（假設(shè)鎖自動失效時間為10秒，則超時時間一般在5-50毫秒之間,我們就假設(shè)超時時間是50ms吧）。如果超時，跳過該master節(jié)點，盡快去嘗試下一個master節(jié)點。
3. 客戶端使用當(dāng)前時間減去開始獲取鎖時間（即步驟1記錄的時間），得到獲取鎖使用的時間。當(dāng)且僅當(dāng)超過一半（N/2+1，這里是5/2+1=3個節(jié)點）的Redis master節(jié)點都獲得鎖，并且使用的時間小于鎖失效時間時，鎖才算獲取成功。（如上圖，10s> 30ms+40ms+50ms+4m0s+50ms）
4. 如果取到了鎖，key的真正有效時間就變啦，需要減去獲取鎖所使用的時間。
5. 如果獲取鎖失?。]有在至少N/2+1個master實例取到鎖，有或者獲取鎖時間已經(jīng)超過了有效時間），客戶端要在所有的master節(jié)點上解鎖（即便有些master節(jié)點根本就沒有加鎖成功，也需要解鎖，以防止有些漏網(wǎng)之魚）。

簡化下步驟就是：

• 按順序向5個master節(jié)點請求加鎖
• 根據(jù)設(shè)置的超時時間來判斷，是不是要跳過該master節(jié)點。
• 如果大于等于3個節(jié)點加鎖成功，并且使用的時間小于鎖的有效期，即可認(rèn)定加鎖成功啦。
• 如果獲取鎖失敗，解鎖！