轉(zhuǎn)發(fā)自 【七種方案奕枢！探討Redis分布式鎖的正確使用姿勢】?https://mp.weixin.qq.com/s/dnaU5x37fj2vJVXu-hxIBQ

日常開發(fā)中娄昆，秒殺下單、搶紅包等等業(yè)務(wù)場景缝彬，都需要用到分布式鎖萌焰。而Redis非常適合作為分布式鎖使用。本文將分七個方案展開谷浅，跟大家探討Redis分布式鎖的正確使用方式扒俯。如果有不正確的地方奶卓，歡迎大家指出哈，一起學習一起進步撼玄。

什么是分布式鎖

方案一：SETNX + EXPIRE

方案二：SETNX + value值是（系統(tǒng)時間+過期時間）

方案三：使用Lua腳本(包含SETNX + EXPIRE兩條指令)

方案四：SET的擴展命令（SET EX PX NX）

方案五：SET EX PX NX ?+ 校驗唯一隨機值,再釋放鎖

方案六: 開源框架~Redisson

方案七：多機實現(xiàn)的分布式鎖Redlock

什么是分布式鎖

?

分布式鎖其實就是夺姑，控制分布式系統(tǒng)不同進程共同訪問共享資源的一種鎖的實現(xiàn)。如果不同的系統(tǒng)或同一個系統(tǒng)的不同主機之間共享了某個臨界資源掌猛，往往需要互斥來防止彼此干擾盏浙，以保證一致性。

?

我們先來看下荔茬，一把靠譜的分布式鎖應(yīng)該有哪些特征：

「互斥性」: 任意時刻废膘，只有一個客戶端能持有鎖。

「鎖超時釋放」：持有鎖超時慕蔚，可以釋放丐黄，防止不必要的資源浪費，也可以防止死鎖孔飒。

「可重入性」:一個線程如果獲取了鎖之后,可以再次對其請求加鎖孵稽。

「高性能和高可用」：加鎖和解鎖需要開銷盡可能低，同時也要保證高可用十偶，避免分布式鎖失效菩鲜。

「安全性」：鎖只能被持有的客戶端刪除，不能被其他客戶端刪除

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

提到Redis的分布式鎖惦积，很多小伙伴馬上就會想到setnx+?expire命令接校。即先用setnx來搶鎖，如果搶到之后狮崩，再用expire給鎖設(shè)置一個過期時間蛛勉，防止鎖忘記了釋放。

?

SETNX 是SET IF NOT EXISTS的簡寫.日常命令格式是SETNX key value睦柴，如果 key不存在诽凌，則SETNX成功返回1，如果這個key已經(jīng)存在了坦敌，則返回0侣诵。

?

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

if（jedis.setnx(key_resource_id,lock_value)?==?1）{?//加鎖

expire（key_resource_id杜顺，100）;?//設(shè)置過期時間

try?{

dosomething??//業(yè)務(wù)請求

}catch(){

}

finally?{

jedis.del(key_resource_id);?//釋放鎖

}

}

但是這個方案中，setnx和expire兩個命令分開了蘸炸，「不是原子操作」躬络。如果執(zhí)行完setnx加鎖，正要執(zhí)行expire設(shè)置過期時間時搭儒，進程crash或者要重啟維護了穷当，那么這個鎖就“長生不老”了提茁，「別的線程永遠獲取不到鎖啦」。

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

為了解決方案一馁菜，「發(fā)生異常鎖得不到釋放的場景」茴扁，有小伙伴認為，可以把過期時間放到setnx的value值里面火邓。如果加鎖失敗丹弱，再拿出value值校驗一下即可德撬。加鎖代碼如下：

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

String?expiresStr?=?String.valueOf(expires);

//?如果當前鎖不存在铲咨，返回加鎖成功

if(jedis.setnx(key_resource_id,?expiresStr)?==?1)?{

returntrue;

}

//?如果鎖已經(jīng)存在，獲取鎖的過期時間

String?currentValueStr?=?jedis.get(key_resource_id);

//?如果獲取到的過期時間蜓洪，小于系統(tǒng)當前時間纤勒，表示已經(jīng)過期

if(currentValueStr?!=?null?&&?Long.parseLong(currentValueStr)?<?System.currentTimeMillis())?{

//?鎖已過期，獲取上一個鎖的過期時間隆檀，并設(shè)置現(xiàn)在鎖的過期時間（不了解redis的getSet命令的小伙伴摇天，可以去官網(wǎng)看下哈）

String?oldValueStr?=?jedis.getSet(key_resource_id,?expiresStr);

if(oldValueStr?!=?null?&&?oldValueStr.equals(currentValueStr))?{

//?考慮多線程并發(fā)的情況，只有一個線程的設(shè)置值和當前值相同恐仑，它才可以加鎖

returntrue;

}

}

//其他情況泉坐，均返回加鎖失敗

returnfalse;

}

這個方案的優(yōu)點是，巧妙移除expire單獨設(shè)置過期時間的操作裳仆，把「過期時間放到setnx的value值」里面來腕让。解決了方案一發(fā)生異常，鎖得不到釋放的問題歧斟。但是這個方案還有別的缺點：

?

過期時間是客戶端自己生成的（System.currentTimeMillis()是當前系統(tǒng)的時間）纯丸，必須要求分布式環(huán)境下，每個客戶端的時間必須同步静袖。

如果鎖過期的時候觉鼻，并發(fā)多個客戶端同時請求過來，都執(zhí)行jedis.getSet()队橙，最終只能有一個客戶端加鎖成功坠陈，但是該客戶端鎖的過期時間，可能被別的客戶端覆蓋

該鎖沒有保存持有者的唯一標識捐康，可能被別的客戶端釋放/解鎖畅姊。

?

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

實際上，我們還可以使用Lua腳本來保證原子性（包含setnx和expire兩條指令）吹由，lua腳本如下：

ifredis.call('setnx',KEYS[1],ARGV[1])?==?1then

redis.call('expire',KEYS[1],ARGV[2])

else

return0

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));

//判斷是否成功

returnresult.equals(1L);

這個方案若未，跟方案二對比，你覺得哪個更好呢倾鲫？

Redis分布式鎖方案方案四：SET的擴展命令（SET EX PX NX）

除了使用粗合，使用Lua腳本萍嬉，保證SETNX + EXPIRE兩條指令的原子性，我們還可以巧用Redis的SET指令擴展參數(shù)Ｏ毒巍（SET key value[EX seconds][PX milliseconds][NX|XX]）壤追，它也是原子性的！

?

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

NX :表示key不存在的時候供屉，才能set成功行冰，也即保證只有第一個客戶端請求才能獲得鎖，而其他客戶端請求只能等其釋放鎖伶丐，才能獲取悼做。

EX seconds :設(shè)定key的過期時間，時間單位是秒哗魂。

PX milliseconds: 設(shè)定key的過期時間肛走，單位為毫秒

XX: 僅當key存在時設(shè)置值

?

偽代碼demo如下：

if（jedis.set(key_resource_id,?lock_value,"NX","EX",?100s)?==?1）{?//加鎖

try?{

dosomething??//業(yè)務(wù)處理

}catch(){

}

finally?{

jedis.del(key_resource_id);?//釋放鎖

}

}

但是呢，這個方案還是可能存在問題：

問題一：「鎖過期釋放了录别，業(yè)務(wù)還沒執(zhí)行完」朽色。假設(shè)線程a獲取鎖成功，一直在執(zhí)行臨界區(qū)的代碼组题。但是100s過去后葫男，它還沒執(zhí)行完。但是崔列，這時候鎖已經(jīng)過期了梢褐，此時線程b又請求過來。顯然線程b就可以獲得鎖成功峻呕，也開始執(zhí)行臨界區(qū)的代碼利职。那么問題就來了，臨界區(qū)的業(yè)務(wù)代碼都不是嚴格串行執(zhí)行的啦瘦癌。

問題二：「鎖被別的線程誤刪」猪贪。假設(shè)線程a執(zhí)行完后，去釋放鎖讯私。但是它不知道當前的鎖可能是線程b持有的（線程a去釋放鎖時热押，有可能過期時間已經(jīng)到了，此時線程b進來占有了鎖）斤寇。那線程a就把線程b的鎖釋放掉了桶癣，但是線程b臨界區(qū)業(yè)務(wù)代碼可能都還沒執(zhí)行完呢。

方案五：SET EX PX NX ?+ 校驗唯一隨機值,再刪除

既然鎖可能被別的線程誤刪娘锁，那我們給value值設(shè)置一個標記當前線程唯一的隨機數(shù)牙寞，在刪除的時候，校驗一下，不就OK了嘛间雀。偽代碼如下：

if（jedis.set(key_resource_id,?uni_request_id,"NX","EX",?100s)?==?1）{?//加鎖

try?{

dosomething??//業(yè)務(wù)處理

}catch(){

}

finally?{

//判斷是不是當前線程加的鎖,是才釋放

if(uni_request_id.equals(jedis.get(key_resource_id)))?{

jedis.del(lockKey);?//釋放鎖

}

}

}

在這里悔详，「判斷是不是當前線程加的鎖」和「釋放鎖」不是一個原子操作。如果調(diào)用jedis.del()釋放鎖的時候惹挟，可能這把鎖已經(jīng)不屬于當前客戶端茄螃，會解除他人加的鎖。

為了更嚴謹连锯，一般也是用lua腳本代替归苍。lua腳本如下：

ifredis.call('get',KEYS[1])?==?ARGV[1]then

returnredis.call('del',KEYS[1])

else

return0

end;

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

方案五還是可能存在「鎖過期釋放，業(yè)務(wù)沒執(zhí)行完」的問題运怖。有些小伙伴認為拼弃，稍微把鎖過期時間設(shè)置長一些就可以啦。其實我們設(shè)想一下驳规，是否可以給獲得鎖的線程肴敛，開啟一個定時守護線程署海，每隔一段時間檢查鎖是否還存在吗购，存在則對鎖的過期時間延長，防止鎖過期提前釋放砸狞。

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

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

Redis分布式鎖方案七：多機實現(xiàn)的分布式鎖Redlock+Redisson

前面六種方案都只是基于單機版的討論，還不是很完美乾胶。其實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è)當前有5個Redis master節(jié)點跺讯，在5臺服務(wù)器上面運行這些Redis實例枢贿。

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

?

1.獲取當前時間，以毫秒為單位刀脏。

2.按順序向5個master節(jié)點請求加鎖局荚。客戶端設(shè)置網(wǎng)絡(luò)連接和響應(yīng)超時時間愈污，并且超時時間要小于鎖的失效時間耀态。（假設(shè)鎖自動失效時間為10秒，則超時時間一般在5-50毫秒之間,我們就假設(shè)超時時間是50ms吧）暂雹。如果超時首装，跳過該master節(jié)點，盡快去嘗試下一個master節(jié)點杭跪。

3.客戶端使用當前時間減去開始獲取鎖時間（即步驟1記錄的時間）仙逻，得到獲取鎖使用的時間。當且僅當超過一半（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é)點加鎖成功粉铐，并且使用的時間小于鎖的有效期疼约，即可認定加鎖成功啦。

如果獲取鎖失敗蝙泼，解鎖程剥！

Redisson實現(xiàn)了redLock版本的鎖，有興趣的小伙伴汤踏，可以去了解一下哈~

參考與感謝

redis系列：分布式鎖[1]

淺析 Redis 分布式鎖解決方案[2]

細說Redis分布式鎖??[3]

Redlock：Redis分布式鎖最牛逼的實現(xiàn)

Reference

[1]

redis系列：分布式鎖:https://juejin.cn/post/6844903656911798285

[2]

淺析 Redis 分布式鎖解決方案:https://www.infoq.cn/article/dvaaj71f4fbqsxmgvdce

[3]

細說Redis分布式鎖??:https://juejin.cn/post/6844904082860146695#heading-3