色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Redis分布式鎖的10個坑

jf_ro2CN3Fa ? 來源:撿田螺的小男孩 ? 2023-07-29 16:31 ? 次閱讀


前言

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

f3c307f0-2db5-11ee-815d-dac502259ad0.png

基于 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ù)邏輯處理
}

這塊代碼是有坑 的,因為setnxexpire兩個命令是分開寫的,并不是原子操作!如果剛要執(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ā)生異常時,鎖得不到釋放的問題 。有小伙伴提出,可以把過期時間 放到setnxvalue里面。如果加鎖失敗,再拿出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ù)處理完,忘記釋放鎖

很多小伙伴,會使用Redisset指令擴(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底層原理圖吧:

f3e7ed68-2db5-11ee-815d-dac502259ad0.png

只要線程加鎖成功,就會啟動一個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)致分布式鎖失效

這是因為:

springAop,會在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)一個可重入的分布式鎖,我們可以參考JDKReentrantLock的設(shè)計思想。實際上,可以直接使用Redisson框架,它是支持可重入鎖的。

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

實現(xiàn)Redis分布式鎖的話,要注意Redis主從復(fù)制的坑 。因為Redis一般都是集群部署的:

f425e1d6-2db5-11ee-815d-dac502259ad0.png

如果線程一在Redismaster節(jié)點上拿到了鎖,但是加鎖的key還沒同步到slave節(jié)點。恰好這時,master節(jié)點發(fā)生故障,一個slave節(jié)點就會升級為master節(jié)點。線程二就可以獲取同個key的鎖啦,但線程一也已經(jīng)拿到鎖了,鎖的安全性就沒了。

為了解決這個問題,Redis作者 antirez提出一種高級的分布式鎖算法RedlockRedlock核心思想是這樣的:

搞多個Redis master部署,以保證它們不會同時宕掉。并且這些master節(jié)點是完全相互獨立的,相互之間不存在數(shù)據(jù)同步。同時,需要確保在這多個master實例上,是與在Redis單實例,使用相同方法來獲取和釋放鎖。

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

f4560f1e-2db5-11ee-815d-dac502259ad0.png

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

  1. 獲取當(dāng)前時間,以毫秒為單位。
  2. 按順序向5master節(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)定加鎖成功啦。
  • 如果獲取鎖失敗,解鎖!

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 代碼
    +關(guān)注

    關(guān)注

    30

    文章

    4779

    瀏覽量

    68524
  • Redis
    +關(guān)注

    關(guān)注

    0

    文章

    374

    瀏覽量

    10871

原文標(biāo)題:Redis分布式鎖的10個坑

文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    redis分布式場景實現(xiàn)

    今天帶大家深入剖析一下Redis分布式,徹底搞懂它。 場景 既然要搞懂Redis分布式,那肯
    的頭像 發(fā)表于 09-25 17:09 ?714次閱讀

    Redis 分布式的正確實現(xiàn)方式

    分布式一般有三種實現(xiàn)方式:1. 數(shù)據(jù)庫樂觀;2. 基于Redis分布式;3. 基于Zoo
    的頭像 發(fā)表于 05-31 14:19 ?3588次閱讀

    Redis分布式真的安全嗎?

    今天我們來聊一聊Redis分布式
    的頭像 發(fā)表于 11-02 14:07 ?1000次閱讀

    一文闡述Redis分布式10

    為了避免并發(fā)請求造成的庫存超賣等問題,我們一般會用到Redis分布式
    的頭像 發(fā)表于 12-29 14:52 ?562次閱讀

    Redis分布式10

    這塊代碼是有 的,因為setnx和expire兩命令是分開寫的,并不是原子操作!如果剛要執(zhí)行完setnx加鎖,正要執(zhí)行expire設(shè)置過期時間時,進(jìn)程crash或者要重啟維護(hù)了,那么這個就“長生不老 ”了,別的線程永遠(yuǎn)獲取
    的頭像 發(fā)表于 01-10 10:38 ?643次閱讀

    分析闡述Redis分布式10

    日常開發(fā)中,經(jīng)常會碰到秒殺搶購等業(yè)務(wù)。為了避免并發(fā)請求造成的庫存超賣等問題,我們一般會用到Redis分布式
    的頭像 發(fā)表于 01-13 14:12 ?1671次閱讀

    深入理解redis分布式

    系統(tǒng)不同進(jìn)程共同訪問共享資源的一種的實現(xiàn)。如果不同的系統(tǒng)或同一系統(tǒng)的不同主機(jī)之間共享了某個臨界資源,往往需要互斥來防止彼此干擾,以保證一致性。 業(yè)界流行的分布式實現(xiàn),一般有這3種
    的頭像 發(fā)表于 10-08 14:13 ?948次閱讀
    深入理解<b class='flag-5'>redis</b><b class='flag-5'>分布式</b><b class='flag-5'>鎖</b>

    redis分布式如何實現(xiàn)

    的情況,分布式的作用就是確保在同一時間只有一客戶端可以訪問共享資源,從而保證數(shù)據(jù)的一致性和正確性。 下面將詳細(xì)介紹Redis分布式
    的頭像 發(fā)表于 11-16 11:29 ?523次閱讀

    redis分布式可能出現(xiàn)的問題

    地討論Redis分布式可能出現(xiàn)的各種問題。 死鎖問題: 在分布式環(huán)境中,當(dāng)多個進(jìn)程或服務(wù)器同時獲取并且彼此互斥時,可能會導(dǎo)致死鎖。例如,
    的頭像 發(fā)表于 11-16 11:40 ?1375次閱讀

    redis分布式死鎖處理方案

    引言: 隨著分布式系統(tǒng)的廣泛應(yīng)用,尤其是在大規(guī)模并發(fā)操作下,對并發(fā)控制的需求越來越高。Redis分布式作為一種常見的分布式
    的頭像 發(fā)表于 11-16 11:44 ?1748次閱讀

    redis分布式的應(yīng)用場景有哪些

    系統(tǒng)中,多個節(jié)點可能同時訪問共享資源,例如數(shù)據(jù)庫、文件系統(tǒng)等。使用Redis分布式可以保證在同一時刻只有一節(jié)點能夠訪問該資源,避免了并發(fā)沖突問題,確保數(shù)據(jù)的一致性。
    的頭像 發(fā)表于 12-04 11:21 ?1428次閱讀

    redis分布式方法

    Redis是一種高性能的分布式緩存和鍵值存儲系統(tǒng),它提供了一種可靠的分布式解決方案。在分布式系統(tǒng)中,由于多個節(jié)點之間的并發(fā)訪問,需要使用
    的頭像 發(fā)表于 12-04 11:22 ?1457次閱讀

    如何實現(xiàn)Redis分布式

    Redis是一開源的內(nèi)存數(shù)據(jù)存儲系統(tǒng),可用于高速讀寫操作。在分布式系統(tǒng)中,為了保證數(shù)據(jù)的一致性和避免競態(tài)條件,常常需要使用分布式來對共享
    的頭像 發(fā)表于 12-04 11:24 ?698次閱讀

    redis分布式可能出現(xiàn)的問題及解決方案

    。 誤刪 Redis分布式通常使用SETNX命令創(chuàng)建,并使用DEL命令刪除。在高并發(fā)情況下,可能會發(fā)生誤刪的情況,即一
    的頭像 發(fā)表于 12-04 11:29 ?967次閱讀

    redis分布式的缺點

    Redis分布式是一種常見的用于解決分布式系統(tǒng)中資源爭用問題的解決方案。盡管Redis分布式
    的頭像 發(fā)表于 12-04 14:05 ?1247次閱讀
    主站蜘蛛池模板: 敌伦小芳的第一次| 欧美精品专区第1页| 亚洲国产cao| 国产AV无码一二三区视频| 欧美性色生活片天天看99顶级| 2021国产精品| 久久精品国产亚洲AV未满十八| 学生精品国产在线视频| 国产成人精品永久免费视频 | 超碰国产人人做人人爽| 免费中文字幕视频| 18动漫在线观看| 老熟女重囗味HDXX| 夜蒲团之5阳性之教| 嗨嗨快播电影| 亚洲精品久久久992KVTV| 国产色情短视频在线网站| 午夜理论在线观看不卡大地影院| 古代荡乳尤物H妓女调教| 日韩亚洲欧美中文高清在线| 成人综合在线观看| 蛇缚dvd| 国产成人精品视频| 无罩看奶禁18| 国产午夜精品久久理论片小说| 小便japanesewctv| 国产在线精品亚洲另类| 亚洲精品久久久久久久蜜臀老牛| 红桃传媒少妇人妻网站无码抽插| 亚洲欧美国产旡码专区| 久久99精品久久久久久园产越南| 一个人HD在线观看免费高清视频 | 亚洲日韩天堂在线中文字幕| 解开白丝老师的短裙猛烈进入| 亚洲欧美激情精品一区二区| 久久999视频| 3DNagoonimation动漫| 男人大臿蕉香蕉大视频| xiao776唯美清纯| 色多多旧版污污破解版| 国产精品久久久久久日本|