1.併發問題
例如,一個操作是修改使用者的賬戶的狀態。修改前需要先讀取,在記憶體裡修改,修改完了,再存進去。
如果這樣的操作同時進行,就會出現併發問題,因為“讀取”和“保持”(設定)這兩個操作不是原子操作。
原子操作是指不會被執行緒排程機制打斷的操作。這種操作一旦開始,就會一直執行到結束,中間不會有任何執行緒切換。
2.分散式鎖的奧義
分散式鎖要實現的最終目標就是在redis裡面佔一個“坑”,當別的程序也要來佔“坑”時,發現那裡已經有一個“大蘿蔔”了,就智慧放棄或者稍後再試。
佔坑一般使用setnx指令,指允許被一個客戶端佔坑。先來先佔,用完了,再呼叫del指令釋放“坑”。
3.佔坑指令--SETNX
setnx key value
將key的值設為value,當且僅當key不存在。
若給定的key已經存在,則SETNX不做任何動作。
SETNX是【SET if NOT eXists】(如果不存在,則SET)的縮寫。
4. 示例
//這裡的冒號“:”就是一個普通的字元,沒特殊含義,它可以是其它任意字元。 > setnx lock:codehole true OK ... do something critical ... > del lock:codehole (integer) 1
5.最佳化1--新增過期時間
待最佳化的地方:如果邏輯執行到中間出現了問題,可能會導致del指令沒有被呼叫,這樣就會陷入死鎖,鎖永遠等不到釋放。
最佳化思路; 在拿到鎖之後,再給鎖加上一個過期時間,比如2s,這樣即使中間出現了異常,也可以保證2s之後,鎖會自動釋放。
> setnx lock:codehole true OK > expire lock:codehole 2 ... do something critical ... > del lock:codehole (integer) 1
6. 繼續最佳化2--過期時間的設定
上面的code,邏輯上還有問題:如果在setnx 和 expire 之間伺服器程序突然掛掉了,可能是因為機器掉電或者是人為造成的,這就會導致expire得不到執行,也會造成死鎖。
這種問題的根源在於setnx和expire是兩條指令而不是原子指令。
如果這兩條指令可以一起執行就不會出現問題,也許你會想到用redis事務來解決,但在這裡不行,因為expire是依賴setnx的執行結果,如果setnx沒搶到鎖,expire是不應該執行的。事務裡沒有if-else分支邏輯,事務的特點是一口氣執行,要麼全部執行,要麼一個都不執行。
Redis 2.8 版本之後,set指令進行了引數擴充套件,使setnx 和 expire指令可以一起執行。
> setnx lock:codehole true ex 5 nx OK ... do something critical ... > del lock:codehole
7. 繼續最佳化3--鎖名稱的設定
Redis的分散式鎖不能解決超時問題,如果在加鎖和釋放鎖之間的邏輯執行得太長,以至於超出了鎖的限時限制,就會出現問題。
因為這時候第一個執行緒持有的鎖過期了,但臨界區的邏輯(指令碼)還沒執行完,而同時第二個執行緒就提前重新持有了這把鎖,導致臨界區程式碼不能得到嚴格的序列執行。
出問題的關鍵點:在於釋放鎖/刪除鎖時,容易把別人新增的鎖釋放掉。最佳化的思路,就是在釋放鎖的時候,判斷下,是不是自己之前新增的鎖。
例如,針對每一個請求,生成一個基於clientid(或者UUID.randomUUID().toString())的value。
即將set指令的value引數設定為一個隨機數,釋放時,先匹配隨機數釋放一致,然後再刪除。
這是為了確保當前執行緒佔有的鎖不會被其它執行緒釋放,除非這個鎖是因為過期了而被伺服器自動釋放。
tag = random.nextint() ##隨機數 if redis.set(key, tag, nx=True, ex=5): do_something() redis.delifequals(key,tag) ##抽象的功能程式碼
但是匹配value和刪除key不是一個原子操作,redis也沒有提供類似的delifequals這樣的指令,需要使用Lua指令碼處理(Lua指令碼可以保證連續多個指令的原子性執行)
# delifequals if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
但這也不是一個完美的方案,它只是相對安全一點,因為如果真的超時了,當前執行緒的邏輯沒有執行完,其它執行緒的邏輯也會乘虛而入。
8. 繼續最佳化4--鎖續期
redis鎖的過期時間能夠自動續期。
使用redis客戶端redisson。redisson在加鎖成功後,會註冊一個定時任務監聽這個鎖,每隔10秒就去檢視這個鎖,如果還持有鎖,就對過期時間進行續期。預設過期時間30秒。
舉例子:假如加鎖的時間是30秒,過10秒檢查一次,一旦加鎖的業務沒有執行完,就會進行一次續期,把鎖的過期時間再次重置成30秒。
1. 加鎖成功後,啟動一個定時任務,每個一段時間檢測是否執行完成業務程式碼,依據是鎖是否還存在。
2. 這個定時任務每隔三分之一時間檢查一次,比如鎖過期時間是30秒,就每隔10秒檢查一次。
3. 如果鎖還存在,就把鎖過期時間繼續設定成30秒。
Redisson框架已經實現了這個流程,名叫看門狗機制(Watch Dog),底層使用 Lua 指令碼實現。
// 獲取 Redisson 鎖 RLock lock = redissonClient.getLock(lock_key); try { // 加鎖,並設定3秒後過期 lock.lock(3, TimeUnit.SECONDS); // 執行業務程式碼 doBusiness(); } catch (Exception e) { System.out.println("加鎖超時"); } finally { // 釋放鎖 lock.unlock(); }
Redisson分散式鎖實現原理
學習參閱宣告
1.《Redis深度歷險--核心原理與應用實踐》
2. 《Redis分散式鎖如何實現續期》 https://www.jb51.net/article/233992.htm
3. 《高併發必備,使用Redis分散式鎖必須注意的10個細節》https://zhuanlan.zhihu.com/p/647085067
4. 【從原理到實戰(2023最新版)】 https://www.bilibili.com/video/BV1Gs4y1Q7Ls?p=6&vd_source=0e347fbc6c2b049143afaa5a15abfc1c