一文闡述Redis分布式鎖的10個(gè)坑

日常開(kāi)發(fā)中，經(jīng)常會(huì)碰到秒殺搶購(gòu)等業(yè)務(wù)。

為了避免并發(fā)請(qǐng)求造成的庫(kù)存超賣(mài)等問(wèn)題，我們一般會(huì)用到Redis分布式鎖。

但是使用Redis分布式鎖，很容易踩坑哦！

本文將給大家分析闡述，Redis分布式鎖的10個(gè)坑！

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

一說(shuō)到實(shí)現(xiàn)Redis的分布式鎖，很多小伙伴馬上就會(huì)想到setnx+ expire命令。也就是說(shuō)，先用setnx來(lái)?yè)屾i，如果搶到之后，再用expire給鎖設(shè)置一個(gè)過(guò)期時(shí)間。

偽代碼如下：

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

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

2.被別的客戶端請(qǐng)求覆蓋（ setnx + value為過(guò)期時(shí)間）

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

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

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

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

//如果獲取到的老的預(yù)期過(guò)期時(shí)間，小于系統(tǒng)當(dāng)前時(shí)間，表示已經(jīng)過(guò)期了
if(oldExpireTimreStr!=null&&Long.parseLong(oldExpireTimreStr)

	

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

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

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

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


	

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

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

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

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

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


	

	小伙伴會(huì)寫(xiě)出如下偽代碼：

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


	

	這塊偽代碼，初看覺(jué)得沒(méi)啥問(wèn)題，但是細(xì)想，不太對(duì)呀。因?yàn)?strong>忘記釋放鎖了！如果每次加鎖成功，都要等到超時(shí)時(shí)間才釋放鎖，是會(huì)有問(wèn)題的。這樣程序不高效，應(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給釋放了

	我們來(lái)看下這塊偽代碼：

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


	

	大家覺(jué)得會(huì)有哪些坑呢？

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

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

	
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. 釋放鎖時(shí)，不是原子性

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

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


	

	因?yàn)榕袛嗍遣皇钱?dāng)前線程加的鎖和釋放鎖不是一個(gè)原子操作。如果調(diào)用unlock(lockKey)釋放鎖的時(shí)候，鎖已經(jīng)過(guò)期，所以這把鎖已經(jīng)可能已經(jīng)不屬于當(dāng)前客戶端，會(huì)解除他人加的鎖。

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

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


	

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

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

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

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

	

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

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

	大家看下這塊偽代碼:

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


	

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

	這是因?yàn)?

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

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

	9.鎖可重入

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

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

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

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

	怎么保存當(dāng)前持有的線程

	怎么維護(hù)加鎖次數(shù)（即重入了多少次）

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

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

	實(shí)現(xiàn)Redis分布式鎖的話，要注意Redis主從復(fù)制的坑。因?yàn)镽edis一般都是集群部署的：

	

	如果線程一在Redis的master節(jié)點(diǎn)上拿到了鎖，但是加鎖的key還沒(méi)同步到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)拿到鎖了，鎖的安全性就沒(méi)了。

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

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

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

	

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

	獲取當(dāng)前時(shí)間，以毫秒為單位。

	按順序向5個(gè)master節(jié)點(diǎn)請(qǐng)求加鎖?？蛻舳嗽O(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í)，跳過(guò)該master節(jié)點(diǎn)，盡快去嘗試下一個(gè)master節(jié)點(diǎn)。

	客戶端使用當(dāng)前時(shí)間減去開(kāi)始獲取鎖時(shí)間（即步驟1記錄的時(shí)間），得到獲取鎖使用的時(shí)間。當(dāng)且僅當(dāng)超過(guò)一半（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í)間。

	如果獲取鎖失?。](méi)有在至少N/2+1個(gè)master實(shí)例取到鎖，有或者獲取鎖時(shí)間已經(jīng)超過(guò)了有效時(shí)間），客戶端要在所有的master節(jié)點(diǎn)上解鎖（即便有些master節(jié)點(diǎn)根本就沒(méi)有加鎖成功，也需要解鎖，以防止有些漏網(wǎng)之魚(yú)）。

	簡(jiǎn)化下步驟就是：

	按順序向5個(gè)master節(jié)點(diǎn)請(qǐng)求加鎖

	根據(jù)設(shè)置的超時(shí)時(shí)間來(lái)判斷，是不是要跳過(guò)該master節(jié)點(diǎn)。

	如果大于等于3個(gè)節(jié)點(diǎn)加鎖成功，并且使用的時(shí)間小于鎖的有效期，即可認(rèn)定加鎖成功啦。

	如果獲取鎖失敗，解鎖！

	審核編輯：湯梓紅