日常開發中,秒殺下單、搶紅包等等業務場景,都需要用到分布式鎖。而Redis非常適合作為分布式鎖使用。本文將分七個方案展開,跟大家探討Redis分布式鎖的正確使用方式。如果有不正確的地方,歡迎大家指出哈,一起學習一起進步。
公眾號:撿田螺的小男孩
什么是分布式鎖
方案一:SETNX + EXPIRE
什么是分布式項目、方案二:SETNX + value值是(系統時間+過期時間)
方案三:使用Lua腳本(包含SETNX + EXPIRE兩條指令)
方案四:SET的擴展命令(SET EX PX NX)
方案五:SET EX PX NX + 校驗唯一隨機值,再釋放鎖
方案六: 開源框架:Redisson
分布式環境。方案七:多機實現的分布式鎖Redlock
?
分布式鎖其實就是,控制分布式系統不同進程共同訪問共享資源的一種鎖的實現。如果不同的系統或同一個系統的不同主機之間共享了某個臨界資源,往往需要互斥來防止彼此干擾,以保證一致性。
我們先來看下,一把靠譜的分布式鎖應該有哪些特征:
分布式處理,?
提到Redis的分布式鎖,很多小伙伴馬上就會想到setnx
+ expire
命令。即先用setnx
來搶鎖,如果搶到之后,再用expire
給鎖設置一個過期時間,防止鎖忘記了釋放。
SETNX 是SET IF NOT EXISTS的簡寫.日常命令格式是SETNX key value,如果 key不存在,則SETNX成功返回1,如果這個key已經存在了,則返回0。
假設某電商網站的某商品做秒殺活動,key可以設置為key_resource_id,value設置任意值,偽代碼如下:
?
if(jedis.setnx(key_resource_id,lock_value) == 1){ //加鎖expire(key_resource_id,100); //設置過期時間try {do something //業務請求}catch(){}finally {jedis.del(key_resource_id); //釋放鎖}
}
分布式??
但是這個方案中,setnx
和expire
兩個命令分開了,不是原子操作。如果執行完setnx
加鎖,正要執行expire
設置過期時間時,進程crash或者要重啟維護了,那么這個鎖就“長生不老”了,別的線程永遠獲取不到鎖啦。
為了解決方案一,發生異常鎖得不到釋放的場景,有小伙伴認為,可以把過期時間放到setnx
的value值里面。如果加鎖失敗,再拿出value值校驗一下即可。加鎖代碼如下:
long expires = System.currentTimeMillis() + expireTime; //系統時間+設置的過期時間
String expiresStr = String.valueOf(expires);// 如果當前鎖不存在,返回加鎖成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {return true;
}
// 如果鎖已經存在,獲取鎖的過期時間
String currentValueStr = jedis.get(key_resource_id);// 如果獲取到的過期時間,小于系統當前時間,表示已經過期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {// 鎖已過期,獲取上一個鎖的過期時間,并設置現在鎖的過期時間(不了解redis的getSet命令的小伙伴,可以去官網看下哈)String oldValueStr = jedis.getSet(key_resource_id, expiresStr);if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {// 考慮多線程并發的情況,只有一個線程的設置值和當前值相同,它才可以加鎖return true;}
}//其他情況,均返回加鎖失敗
return false;
}
?
這個方案的優點是,巧妙移除expire
單獨設置過期時間的操作,把過期時間放到setnx的value值里面來。解決了方案一發生異常,鎖得不到釋放的問題。但是這個方案還有別的缺點:
- 過期時間是客戶端自己生成的(System.currentTimeMillis()是當前系統的時間),必須要求分布式環境下,每個客戶端的時間必須同步。
- 如果鎖過期的時候,并發多個客戶端同時請求過來,都執行jedis.getSet(),最終只能有一個客戶端加鎖成功,但是該客戶端鎖的過期時間,可能被別的客戶端覆蓋
- 該鎖沒有保存持有者的唯一標識,可能被別的客戶端釋放/解鎖。
redis的分布式鎖。實際上,我們還可以使用Lua腳本來保證原子性(包含setnx和expire兩條指令),lua腳本如下:
if redis.call('setnx',KEYS[1],ARGV[1]) == 1 thenredis.call('expire',KEYS[1],ARGV[2])
elsereturn 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);
這個方案還是有缺點的哦,至于哪些缺點,你先思考一下。也可以想下。跟方案二對比,哪個更好?
?
分布式部署方案?除了使用,使用Lua腳本,保證SETNX + EXPIRE
兩條指令的原子性,我們還可以巧用Redis的SET指令擴展參數!(SET key value[EX seconds][PX milliseconds][NX|XX]
),它也是原子性的!
SET key value[EX seconds][PX milliseconds][NX|XX]
- NX :表示key不存在的時候,才能set成功,也即保證只有第一個客戶端請求才能獲得鎖,而其他客戶端請求只能等其釋放鎖,才能獲取。
- EX seconds :設定key的過期時間,時間單位是秒。
- PX milliseconds: 設定key的過期時間,單位為毫秒
- XX: 僅當key存在時設置值
偽代碼demo如下:
if(jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1){ //加鎖try {do something //業務處理}catch(){}finally {jedis.del(key_resource_id); //釋放鎖}
}
?
但是呢,這個方案還是可能存在問題:
集群和分布式的區別,
?
既然鎖可能被別的線程誤刪,那我們給value值設置一個標記當前線程唯一的隨機數,在刪除的時候,校驗一下,不就OK了嘛。偽代碼如下:
if(jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1){ //加鎖try {do something //業務處理}catch(){}finally {//判斷是不是當前線程加的鎖,是才釋放if (uni_request_id.equals(jedis.get(key_resource_id))) {jedis.del(lockKey); //釋放鎖}}
}
?
在這里,判斷是不是當前線程加的鎖和釋放鎖不是一個原子操作。如果調用jedis.del()釋放鎖的時候,可能這把鎖已經不屬于當前客戶端,會解除他人加的鎖。
redis實現分布式鎖最好方案、為了更嚴謹,一般也是用lua腳本代替。lua腳本如下:
if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1])
elsereturn 0
end;
?
方案五還是可能存在鎖過期釋放,業務沒執行完的問題。有些小伙伴認為,稍微把鎖過期時間設置長一些就可以啦。其實我們設想一下,是否可以給獲得鎖的線程,開啟一個定時守護線程,每隔一段時間檢查鎖是否還存在,存在則對鎖的過期時間延長,防止鎖過期提前釋放。
當前開源框架Redisson解決了這個問題。我們一起來看下Redisson底層原理圖吧:
分布式集群方案、?
只要線程一加鎖成功,就會啟動一個watch dog
看門狗,它是一個后臺線程,會每隔10秒檢查一下,如果線程1還持有鎖,那么就會不斷的延長鎖key的生存時間。因此,Redisson就是使用Redisson解決了鎖過期釋放,業務沒執行完問題。
前面六種方案都只是基于單機版的討論,還不是很完美。其實Redis一般都是集群部署的:
?
分布式方案。如果線程一在Redis的master節點上拿到了鎖,但是加鎖的key還沒同步到slave節點。恰好這時,master節點發生故障,一個slave節點就會升級為master節點。線程二就可以獲取同個key的鎖啦,但線程一也已經拿到鎖了,鎖的安全性就沒了。
為了解決這個問題,Redis作者 antirez提出一種高級的分布式鎖算法:Redlock。Redlock核心思想是這樣的:
搞多個Redis master部署,以保證它們不會同時宕掉。并且這些master節點是完全相互獨立的,相互之間不存在數據同步。同時,需要確保在這多個master實例上,是與在Redis單實例,使用相同方法來獲取和釋放鎖。
我們假設當前有5個Redis master節點,在5臺服務器上面運行這些Redis實例。
分布式部署和集群部署、?
RedLock的實現步驟:如下
- 1.獲取當前時間,以毫秒為單位。
- 2.按順序向5個master節點請求加鎖。客戶端設置網絡連接和響應超時時間,并且超時時間要小于鎖的失效時間。(假設鎖自動失效時間為10秒,則超時時間一般在5-50毫秒之間,我們就假設超時時間是50ms吧)。如果超時,跳過該master節點,盡快去嘗試下一個master節點。
- 3.客戶端使用當前時間減去開始獲取鎖時間(即步驟1記錄的時間),得到獲取鎖使用的時間。當且僅當超過一半(N/2+1,這里是5/2+1=3個節點)的Redis master節點都獲得鎖,并且使用的時間小于鎖失效時間時,鎖才算獲取成功。(如上圖,10s> 30ms+40ms+50ms+4m0s+50ms)
- 如果取到了鎖,key的真正有效時間就變啦,需要減去獲取鎖所使用的時間。
- 如果獲取鎖失敗(沒有在至少N/2+1個master實例取到鎖,有或者獲取鎖時間已經超過了有效時間),客戶端要在所有的master節點上解鎖(即便有些master節點根本就沒有加鎖成功,也需要解鎖,以防止有些漏網之魚)。
簡化下步驟就是:
從事IT行業多年,用Java,前端,知Python,有多年的開發經驗。如果你正在入門學習Java可以申請加入我的Java學習交流群:735721532。文件我上傳了我做Java這幾年整理的一些學習手冊,面試題,開發工具,PDF文檔書籍教程,需要的話你們都可以自行來獲取下載。
?
?
版权声明:本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
图1:双十一活动图
活动时间:2017年10月23日——2017年11月13日
活动产品:几何画板
活动优惠" alt="几何画板领衔起跑,提前启动双十一!">
工作时间:8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态