面試被吊打积锅!正確打開Redis分布式鎖的七種方案爽彤,漲見識(shí)了

前言

日常開發(fā)中,秒殺下單缚陷、搶紅包等等業(yè)務(wù)場景适篙,都需要用到分布式鎖。而Redis非常適合作為分布式鎖使用箫爷。本文將分七個(gè)方案展開嚷节,跟大家探討Redis分布式鎖的正確使用方式。如果有不正確的地方虎锚,歡迎大家指出哈硫痰,一起學(xué)習(xí)一起進(jìn)步。

面試被吊打翁都!正確打開Redis分布式鎖的七種方案碍论,漲見識(shí)了
  • 什么是分布式鎖
  • 方案一:SETNX + EXPIRE
  • 方案二:SETNX + value值是(系統(tǒng)時(shí)間+過期時(shí)間)
  • 方案三:使用Lua腳本(包含SETNX + EXPIRE兩條指令)
  • 方案四:SET的擴(kuò)展命令(SET EX PX NX)
  • 方案五:SET EX PX NX + 校驗(yàn)唯一隨機(jī)值,再釋放鎖
  • 方案六: 開源框架~Redisson
  • 方案七:多機(jī)實(shí)現(xiàn)的分布式鎖Redlock

什么是分布式鎖

分布式鎖其實(shí)就是,控制分布式系統(tǒng)不同進(jìn)程共同訪問共享資源的一種鎖的實(shí)現(xiàn)柄慰。如果不同的系統(tǒng)或同一個(gè)系統(tǒng)的不同主機(jī)之間共享了某個(gè)臨界資源鳍悠,往往需要互斥來防止彼此干擾,以保證一致性坐搔。

我們先來看下藏研,一把靠譜的分布式鎖應(yīng)該有哪些特征:

面試被吊打!正確打開Redis分布式鎖的七種方案概行,漲見識(shí)了
  • 「互斥性」: 任意時(shí)刻蠢挡,只有一個(gè)客戶端能持有鎖。
  • 「鎖超時(shí)釋放」:持有鎖超時(shí)凳忙,可以釋放业踏,防止不必要的資源浪費(fèi),也可以防止死鎖涧卵。
  • 「可重入性」:一個(gè)線程如果獲取了鎖之后,可以再次對其請求加鎖勤家。
  • 「高性能和高可用」:加鎖和解鎖需要開銷盡可能低,同時(shí)要保證高可用柳恐,避免分布式鎖失效伐脖。
  • 「安全性」:鎖只能被持有的客戶端刪除,不能被其他客戶端刪除

Redis分布式鎖方案一:SETNX + EXPIRE

提到Redis的分布式鎖乐设,很多小伙伴馬上就會(huì)想到setnx+ expire命令讼庇。即先用setnx來搶鎖,如果搶到之后近尚,再用expire給鎖設(shè)置一個(gè)過期時(shí)間蠕啄,防止鎖忘記了釋放。

SETNX 是SET IF NOT EXISTS的簡寫.日常命令格式是SETNX key value戈锻,如果 key不存在歼跟,則SETNX成功返回1却嗡,如果這個(gè)key已經(jīng)存在了,則返回0嘹承。

假設(shè)某電商網(wǎng)站的某商品做秒殺活動(dòng),key可以設(shè)置為key_resource_id,value設(shè)置任意值如庭,偽代碼如下:

if(jedis.setnx(key_resource_id,lock_value) == 1){ //加鎖 
    expire(key_resource_id叹卷,100); //設(shè)置過期時(shí)間 
    try { 
        do something  //業(yè)務(wù)請求 
    }catch(){ 
  } 
  finally { 
       jedis.del(key_resource_id); //釋放鎖 
    } 
} 

但是這個(gè)方案中,setnx和expire兩個(gè)命令分開了坪它,「不是原子操作」骤竹。如果執(zhí)行完setnx加鎖,正要執(zhí)行expire設(shè)置過期時(shí)間時(shí)往毡,進(jìn)程crash或者要重啟維護(hù)了蒙揣,那么這個(gè)鎖就“長生不老”了,「別的線程永遠(yuǎn)獲取不到鎖啦」开瞭。

Redis分布式鎖方案二:SETNX + value值是(系統(tǒng)時(shí)間+過期時(shí)間)

為了解決方案一懒震,「發(fā)生異常鎖得不到釋放的場景」,有小伙伴認(rèn)為嗤详,可以把過期時(shí)間放到setnx的value值里面个扰。如果加鎖失敗,再拿出value值校驗(yàn)一下即可葱色。加鎖代碼如下:

long expires = System.currentTimeMillis() + expireTime; //系統(tǒng)時(shí)間+設(shè)置的過期時(shí)間 
String expiresStr = String.valueOf(expires); 

// 如果當(dāng)前鎖不存在递宅,返回加鎖成功 
if (jedis.setnx(key_resource_id, expiresStr) == 1) { 
        return true; 
}  
// 如果鎖已經(jīng)存在,獲取鎖的過期時(shí)間 
String currentValueStr = jedis.get(key_resource_id); 

// 如果獲取到的過期時(shí)間苍狰,小于系統(tǒng)當(dāng)前時(shí)間办龄,表示已經(jīng)過期 
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) { 

     // 鎖已過期逗旁,獲取上一個(gè)鎖的過期時(shí)間朵你,并設(shè)置現(xiàn)在鎖的過期時(shí)間(不了解redis的getSet命令的小伙伴,可以去官網(wǎng)看下哈) 
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr); 

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

//其他情況玷禽,均返回加鎖失敗 
return false; 
} 

這個(gè)方案的優(yōu)點(diǎn)是,巧妙移除expire單獨(dú)設(shè)置過期時(shí)間的操作呀打,把「過期時(shí)間放到setnx的value值」里面來矢赁。解決了方案一發(fā)生異常,鎖得不到釋放的問題贬丛。但是這個(gè)方案還有別的缺點(diǎn):

  • 過期時(shí)間是客戶端自己生成的(System.currentTimeMillis()是當(dāng)前系統(tǒng)的時(shí)間)撩银,必須要求分布式環(huán)境下,每個(gè)客戶端的時(shí)間必須同步豺憔。
  • 如果鎖過期的時(shí)候额获,并發(fā)多個(gè)客戶端同時(shí)請求過來够庙,都執(zhí)行jedis.getSet(),最終只能有一個(gè)客戶端加鎖成功抄邀,但是該客戶端鎖的過期時(shí)間耘眨,可能被別的客戶端覆蓋
  • 該鎖沒有保存持有者的唯一標(biāo)識(shí),可能被別的客戶端釋放/解鎖境肾。

Redis分布式鎖方案三:使用Lua腳本(包含SETNX + EXPIRE兩條指令)

實(shí)際上剔难,我們還可以使用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); 

這個(gè)方案奥喻,跟方案二對比偶宫,你覺得哪個(gè)更好呢?

Redis分布式鎖方案方案四:SET的擴(kuò)展命令(SET EX PX NX)

除了使用,使用Lua腳本环鲤,保證SETNX + EXPIRE兩條指令的原子性纯趋,我們還可以巧用Redis的SET指令擴(kuò)展參數(shù)!(SET key value[EX seconds][PX milliseconds][NX|XX]),它也是原子性的!

SET key value[EX seconds][PX milliseconds][NX|XX]

  • NX :表示key不存在的時(shí)候冷离,才能set成功吵冒,也即保證只有第一個(gè)客戶端請求才能獲得鎖,而其他客戶端請求只能等其釋放鎖西剥,才能獲取桦锄。
  • EX seconds :設(shè)定key的過期時(shí)間,時(shí)間單位是秒蔫耽。
  • PX milliseconds: 設(shè)定key的過期時(shí)間结耀,單位為毫秒
  • XX: 僅當(dāng)key存在時(shí)設(shè)置值

偽代碼demo如下:

if(jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1){ //加鎖 
    try { 
        do something  //業(yè)務(wù)處理 
    }catch(){ 
  } 
  finally { 
       jedis.del(key_resource_id); //釋放鎖 
    } 
} 

但是呢,這個(gè)方案還是可能存在問題:

  • 問題一:「鎖過期釋放了匙铡,業(yè)務(wù)還沒執(zhí)行完」图甜。假設(shè)線程a獲取鎖成功,一直在執(zhí)行臨界區(qū)的代碼鳖眼。但是100s過去后黑毅,它還沒執(zhí)行完。但是钦讳,這時(shí)候鎖已經(jīng)過期了矿瘦,此時(shí)線程b又請求過來。顯然線程b就可以獲得鎖成功愿卒,也開始執(zhí)行臨界區(qū)的代碼缚去。那么問題就來了,臨界區(qū)的業(yè)務(wù)代碼都不是嚴(yán)格串行執(zhí)行的啦琼开。
  • 問題二:「鎖被別的線程誤刪」易结。假設(shè)線程a執(zhí)行完后,去釋放鎖。但是它不知道當(dāng)前的鎖可能是線程b持有的(線程a去釋放鎖時(shí)搞动,有可能過期時(shí)間已經(jīng)到了躏精,此時(shí)線程b進(jìn)來占有了鎖)。那線程a就把線程b的鎖釋放掉了鹦肿,但是線程b臨界區(qū)業(yè)務(wù)代碼可能都還沒執(zhí)行完呢矗烛。

方案五:SET EX PX NX + 校驗(yàn)唯一隨機(jī)值,再刪除

既然鎖可能被別的線程誤刪,那我們給value值設(shè)置一個(gè)標(biāo)記當(dāng)前線程唯一的隨機(jī)數(shù)箩溃,在刪除的時(shí)候高诺,校驗(yàn)一下,不就OK了嘛碾篡。偽代碼如下:

if(jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1){ //加鎖 
    try { 
        do something  //業(yè)務(wù)處理 
    }catch(){ 
  } 
  finally { 
       //判斷是不是當(dāng)前線程加的鎖,是才釋放 
       if (uni_request_id.equals(jedis.get(key_resource_id))) { 
        jedis.del(lockKey); //釋放鎖 
        } 
    } 
} 

在這里,「判斷是不是當(dāng)前線程加的鎖」和「釋放鎖」不是一個(gè)原子操作筏餐。如果調(diào)用jedis.del()釋放鎖的時(shí)候开泽,可能這把鎖已經(jīng)不屬于當(dāng)前客戶端,會(huì)解除他人加的鎖魁瞪。

[圖片上傳失敗...(image-4b1b3-1615208743317)]

為了更嚴(yán)謹(jǐn)穆律,一般也是用lua腳本代替。lua腳本如下:

if redis.call('get',KEYS[1]) == ARGV[1] then  
   return redis.call('del',KEYS[1])  
else 
   return 0 
end; 

Redis分布式鎖方案六:Redisson框架

方案五還是可能存在「鎖過期釋放导俘,業(yè)務(wù)沒執(zhí)行完」的問題峦耘。有些小伙伴認(rèn)為,稍微把鎖過期時(shí)間設(shè)置長一些就可以啦旅薄。其實(shí)我們設(shè)想一下辅髓,是否可以給獲得鎖的線程,開啟一個(gè)定時(shí)守護(hù)線程少梁,每隔一段時(shí)間檢查鎖是否還存在洛口,存在則對鎖的過期時(shí)間延長,防止鎖過期提前釋放凯沪。

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

[圖片上傳失敗...(image-b2716-1615208743317)]

只要線程一加鎖成功,就會(huì)啟動(dòng)一個(gè)watch dog看門狗妨马,它是一個(gè)后臺(tái)線程挺举,會(huì)每隔10秒檢查一下,如果線程1還持有鎖烘跺,那么就會(huì)不斷地延長鎖key的生存時(shí)間湘纵。因此,Redisson就是使用Redisson解決了「鎖過期釋放滤淳,業(yè)務(wù)沒執(zhí)行完」問題瞻佛。

Redis分布式鎖方案七:多機(jī)實(shí)現(xiàn)的分布式鎖Redlock+Redisson

前面六種方案都只是基于單機(jī)版的討論,還不是很完美。其實(shí)Redis一般都是集群部署的:

面試被吊打伤柄!正確打開Redis分布式鎖的七種方案绊困,漲見識(shí)了

如果線程一在Redis的master節(jié)點(diǎn)上拿到了鎖,但是加鎖的key還沒同步到slave節(jié)點(diǎn)适刀。恰好這時(shí)秤朗,master節(jié)點(diǎn)發(fā)生故障,一個(gè)slave節(jié)點(diǎn)就會(huì)升級(jí)為master節(jié)點(diǎn)笔喉。線程二就可以獲取同個(gè)key的鎖啦取视,但線程一也已經(jīng)拿到鎖了,鎖的安全性就沒了常挚。

為了解決這個(gè)問題作谭,Redis作者 antirez提出一種高級(jí)的分布式鎖算法:Redlock。Redlock核心思想是這樣的:

搞多個(gè)Redis master部署奄毡,以保證它們不會(huì)同時(shí)宕掉折欠。并且這些master節(jié)點(diǎn)是完全相互獨(dú)立的,相互之間不存在數(shù)據(jù)同步吼过。同時(shí)锐秦,需要確保在這多個(gè)master實(shí)例上,是與在Redis單實(shí)例盗忱,使用相同方法來獲取和釋放鎖酱床。

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

面試被吊打扇谣!正確打開Redis分布式鎖的七種方案,漲見識(shí)了

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

1.獲取當(dāng)前時(shí)間闲昭,以毫秒為單位揍堕。

2.按順序向5個(gè)master節(jié)點(diǎn)請求加鎖√乐剑客戶端設(shè)置網(wǎng)絡(luò)連接和響應(yīng)超時(shí)時(shí)間衩茸,并且超時(shí)時(shí)間要小于鎖的失效時(shí)間。(假設(shè)鎖自動(dòng)失效時(shí)間為10秒贮泞,則超時(shí)時(shí)間一般在5-50毫秒之間,我們就假設(shè)超時(shí)時(shí)間是50ms吧)楞慈。如果超時(shí),跳過該master節(jié)點(diǎn)啃擦,盡快去嘗試下一個(gè)master節(jié)點(diǎn)囊蓝。

3.客戶端使用當(dāng)前時(shí)間減去開始獲取鎖時(shí)間(即步驟1記錄的時(shí)間),得到獲取鎖使用的時(shí)間令蛉。當(dāng)且僅當(dāng)超過一半(N/2+1聚霜,這里是5/2+1=3個(gè)節(jié)點(diǎn))的Redis master節(jié)點(diǎn)都獲得鎖狡恬,并且使用的時(shí)間小于鎖失效時(shí)間時(shí),鎖才算獲取成功蝎宇。(如上圖弟劲,10s> 30ms+40ms+50ms+4m0s+50ms)

如果取到了鎖,key的真正有效時(shí)間就變啦姥芥,需要減去獲取鎖所使用的時(shí)間兔乞。

如果獲取鎖失敗(沒有在至少N/2+1個(gè)master實(shí)例取到鎖,又或者獲取鎖時(shí)間已經(jīng)超過了有效時(shí)間)凉唐,客戶端要在所有的master節(jié)點(diǎn)上解鎖(即便有些master節(jié)點(diǎn)根本就沒有加鎖成功庸追,也需要解鎖,以防止有些漏網(wǎng)之魚)台囱。

簡化下步驟就是:

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

Redisson實(shí)現(xiàn)了redLock版本的鎖,有興趣的小伙伴车伞,可以去了解一下哈~

以上就是有關(guān)Redis鎖的七種方案择懂,希望可以對大家學(xué)習(xí)Redis有所幫助,喜歡的小伙伴可以幫忙轉(zhuǎn)發(fā)+關(guān)注另玖,感謝大家困曙!LZ也會(huì)不定時(shí)更新干貨!

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末谦去,一起剝皮案震驚了整個(gè)濱河市慷丽,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌鳄哭,老刑警劉巖要糊,帶你破解...
    沈念sama閱讀 206,968評論 6 482
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異妆丘,居然都是意外死亡锄俄,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,601評論 2 382
  • 文/潘曉璐 我一進(jìn)店門勺拣,熙熙樓的掌柜王于貴愁眉苦臉地迎上來奶赠,“玉大人,你說我怎么就攤上這事药有∫愀辏” “怎么了?”我有些...
    開封第一講書人閱讀 153,220評論 0 344
  • 文/不壞的土叔 我叫張陵,是天一觀的道長苇经。 經(jīng)常有香客問我赘理,道長,這世上最難降的妖魔是什么塑陵? 我笑而不...
    開封第一講書人閱讀 55,416評論 1 279
  • 正文 為了忘掉前任感憾,我火速辦了婚禮,結(jié)果婚禮上令花,老公的妹妹穿的比我還像新娘阻桅。我一直安慰自己,他們只是感情好兼都,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,425評論 5 374
  • 文/花漫 我一把揭開白布嫂沉。 她就那樣靜靜地躺著,像睡著了一般扮碧。 火紅的嫁衣襯著肌膚如雪趟章。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,144評論 1 285
  • 那天慎王,我揣著相機(jī)與錄音蚓土,去河邊找鬼。 笑死赖淤,一個(gè)胖子當(dāng)著我的面吹牛蜀漆,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播咱旱,決...
    沈念sama閱讀 38,432評論 3 401
  • 文/蒼蘭香墨 我猛地睜開眼确丢,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了吐限?” 一聲冷哼從身側(cè)響起鲜侥,我...
    開封第一講書人閱讀 37,088評論 0 261
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎诸典,沒想到半個(gè)月后描函,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,586評論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡狐粱,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,028評論 2 325
  • 正文 我和宋清朗相戀三年赘阀,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片脑奠。...
    茶點(diǎn)故事閱讀 38,137評論 1 334
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡基公,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出宋欺,到底是詐尸還是另有隱情轰豆,我是刑警寧澤胰伍,帶...
    沈念sama閱讀 33,783評論 4 324
  • 正文 年R本政府宣布,位于F島的核電站酸休,受9級(jí)特大地震影響骂租,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜斑司,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,343評論 3 307
  • 文/蒙蒙 一渗饮、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧宿刮,春花似錦互站、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,333評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至磕潮,卻和暖如春翠胰,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背自脯。 一陣腳步聲響...
    開封第一講書人閱讀 31,559評論 1 262
  • 我被黑心中介騙來泰國打工之景, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人膏潮。 一個(gè)月前我還...
    沈念sama閱讀 45,595評論 2 355
  • 正文 我出身青樓锻狗,卻偏偏與公主長得像,于是被迫代替她去往敵國和親戏罢。 傳聞我的和親對象是個(gè)殘疾皇子屋谭,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,901評論 2 345

推薦閱讀更多精彩內(nèi)容