Redis分布式鎖使用及說明
Redis分布式鎖
如果追求高可用性(AP) 就采用redis
如果追求高一致性(CP) 就采用zookeeper
加鎖方式
set lockKey uniqueId NX PX expireTime
lockKey
可以根據業(yè)務自己定義(如訂單)uniqueId
是為了不解錯鎖(uniqueId可以是session Id 或者線程Id等)
怎么會解錯鎖?舉個小案例吧
- S1 獲得Lock,ttl時間5s,實際執(zhí)行了7s
- S2 獲得Lock,ttl時間5s,實際執(zhí)行了4s
如果沒有uniqueId S1在第7s的時候解鎖,或解了S2的鎖
NX
代表當前不存在鎖的時候才能加鎖成功PX
毫秒過期時間,如果是秒就用ES
解鎖方式
通過lua腳本實現(xiàn)原子操作,先進行uniqueId對比操作,如果相同,則執(zhí)行del解鎖操作
if redis.call("GET",KEYS[1]) == ARGV[1] then return redis.call("DEL",KEYS[1]) else return 0 end
續(xù)期
當分布式鎖到達了超時時間,但是業(yè)務并沒有完成,則將對鎖進行續(xù)期
S1 獲得Lock,ttl時間5s,實際執(zhí)行了7s,如果沒有續(xù)期那么S1后2秒就沒有鎖
續(xù)期的兩種方式:
- 開啟一個后臺守護線程,每隔3秒對key設置ttl時間5S進行續(xù)期,當主線程執(zhí)行完操作之后,對key進行解鎖,那么守護進行也隨之消亡
- 采用異步任務,獲得鎖后,把所有鎖的線程放到一個Map里,然后每隔幾秒進行輪詢,如果客戶端還持有鎖(即Map中還存在),就延長ttl時間
RedLock算法對應的場景 主節(jié)點掛掉后,lockkey還未同步到從節(jié)點,導致從節(jié)點上沒有l(wèi)ockkey(發(fā)生概率很小,面試官喜歡在AP模型里解決CP模型的問題)
- 對3個完全獨立的redis主服務器一次獲得鎖(一般要基數(shù)個,為了少數(shù)服從多數(shù))
- 如圖請求時間4000-1000=3s小于TTL時間5s,并且至少有半數(shù)(大于2個)獲得鎖,才算真正獲得鎖
缺點(已廢棄,不常用,因此只學習算法思想)
- 復雜度高,需要設計一些算法去實現(xiàn)
- 不可靠,如果redis主服務器宕機,會影響到鎖的使用(即少數(shù)服從多數(shù)會受影響)
- 性能瓶頸,需要訪問多個redis實例
- 另外最要命的是還需要求所有redis主服務器的系統(tǒng)時間一致性
總結
以上為個人經驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關文章
Redis出現(xiàn)(error)NOAUTH?Authentication?required.報錯的解決辦法(秒懂!)
這篇文章主要給大家介紹了關于Redis出現(xiàn)(error)NOAUTH?Authentication?required.報錯的解決辦法,對于 這個錯誤這通常是因為Redis服務器需要密碼進行身份驗證,但客戶端沒有提供正確的身份驗證信息導致的,需要的朋友可以參考下2024-03-03SpringSession通過Redis統(tǒng)計在線用戶數(shù)量的實現(xiàn)代碼
這篇文章主要介紹了SpringSession通過Redis統(tǒng)計在線用戶數(shù)量,本文通過實例代碼給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-04-04Spring?Boot?整合Redis?實現(xiàn)優(yōu)惠卷秒殺?一人一單功能
這篇文章主要介紹了Spring?Boot?整合Redis?實現(xiàn)優(yōu)惠卷秒殺?一人一單,在分布式系統(tǒng)下,高并發(fā)的場景下,會出現(xiàn)此類庫存超賣問題,本篇文章介紹了采用樂觀鎖來解決,需要的朋友可以參考下2022-09-09在Redis集群中使用pipeline批量插入的實現(xiàn)方法
這篇文章主要介紹了在Redis集群中使用pipeline批量插入的實現(xiàn)方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2019-05-05