前言
日常開發(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)限、工作流、三方登錄、支付、短信、商城等功能
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è)置過期時間了 。如果程序在運(yùn)行期間,機(jī)器突然掛了,代碼層面沒有走到finally
代碼塊,即在宕機(jī)前,鎖并沒有被刪除掉,這樣的話,就沒辦法保證解鎖,所以這里需要給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ù)器上面運(yùn)行這些Redis
實例。
RedLock的實現(xiàn)步驟如下:
- 獲取當(dāng)前時間,以毫秒為單位。
-
按順序向
5
個master
節(jié)點請求加鎖。客戶端設(shè)置網(wǎng)絡(luò)連接和響應(yīng)超時時間,并且超時時間要小于鎖的失效時間。(假設(shè)鎖自動失效時間為10
秒,則超時時間一般在5-50
毫秒之間,我們就假設(shè)超時時間是50ms
吧)。如果超時,跳過該master
節(jié)點,盡快去嘗試下一個master
節(jié)點。 -
客戶端使用當(dāng)前時間減去開始獲取鎖時間(即步驟
1
記錄的時間),得到獲取鎖使用的時間。當(dāng)且僅當(dāng)超過一半(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ù)設(shè)置的超時時間來判斷,是不是要跳過該master節(jié)點。
- 如果大于等于3個節(jié)點加鎖成功,并且使用的時間小于鎖的有效期,即可認(rèn)定加鎖成功啦。
- 如果獲取鎖失敗,解鎖!
-
代碼
+關(guān)注
關(guān)注
30文章
4779瀏覽量
68524 -
Redis
+關(guān)注
關(guān)注
0文章
374瀏覽量
10871
原文標(biāo)題:Redis分布式鎖的10個坑
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論