Redis 分布式鎖全解從 SETNX 到 Redisson 看門狗再到 RedLock單機(jī)環(huán)境下加把synchronized鎖就能搞定并發(fā)為什么上了微服務(wù)就不靈了因?yàn)閟ynchronized的鎖是JVM 進(jìn)程內(nèi)的鎖管得了單個(gè)進(jìn)程管不了多個(gè)進(jìn)程。訂單服務(wù)一擴(kuò)容到 3 個(gè)實(shí)例三個(gè)進(jìn)程同時(shí)扣庫(kù)存超賣照樣發(fā)生——這就是分布式鎖要解決的問(wèn)題。本文按一條演進(jìn)鏈講透單機(jī)鎖為什么不夠 → 分布式鎖的評(píng)判標(biāo)準(zhǔn) → Redis 實(shí)現(xiàn)從 SETNX 到 Redisson 看門狗再到 RedLock 的五代演進(jìn) → 常見(jiàn)坑與實(shí)戰(zhàn)選型?？赐昴隳苷f(shuō)清手寫 Redis 鎖和 Redisson 到底差在哪“RedLock 為什么吵了十年還沒(méi)定論”。一、先厘清單機(jī)鎖為什么不夠1.1 并發(fā)問(wèn)題的本質(zhì)并發(fā)問(wèn)題的根源只有一個(gè)多個(gè)執(zhí)行單元同時(shí)讀寫了共享資源且讀寫不是原子的。典型場(chǎng)景電商扣庫(kù)存兩個(gè)請(qǐng)求同時(shí)讀到庫(kù)存 1各自減一都寫回 0——實(shí)際賣出 2 件庫(kù)存變 0超賣。重復(fù)提交兩個(gè)請(qǐng)求同時(shí)處理同一筆訂單各執(zhí)行一遍發(fā)貨邏輯。解決思路也只有一個(gè)把讀-改-寫變成互斥的臨界區(qū)同一時(shí)刻只允許一個(gè)執(zhí)行單元進(jìn)入。1.2 synchronized 的邊界進(jìn)程內(nèi)鎖synchronized/ReentrantLock是基于 JVM 內(nèi)存模型實(shí)現(xiàn)的鎖它的作用域是單個(gè) JVM 進(jìn)程。判斷依據(jù)很簡(jiǎn)單鎖對(duì)象存在堆內(nèi)存里屬于某個(gè)進(jìn)程別的進(jìn)程既看不到這把鎖也不受它約束。所以當(dāng)應(yīng)用是單實(shí)例部署時(shí)進(jìn)程內(nèi)鎖完全夠用一旦變成多實(shí)例 / 微服務(wù)部署同樣的業(yè)務(wù)代碼在 N 個(gè) JVM 里各跑各的進(jìn)程內(nèi)鎖形同虛設(shè)。 重點(diǎn)分布式鎖的本質(zhì)是把互斥的判定點(diǎn)從進(jìn)程內(nèi)搬到所有進(jìn)程都能訪問(wèn)的公共組件上Redis、ZooKeeper、etcd、數(shù)據(jù)庫(kù)都行。1.3 分布式鎖的定義與核心要求分布式鎖讓多個(gè)進(jìn)程在訪問(wèn)共享資源時(shí)通過(guò)一個(gè)外部協(xié)調(diào)組件實(shí)現(xiàn)互斥的機(jī)制。一把合格的分布式鎖至少要滿足要求含義違反的后果互斥性任意時(shí)刻只有一個(gè)客戶端持有鎖并發(fā)進(jìn)入臨界區(qū)數(shù)據(jù)錯(cuò)亂防死鎖持有者崩潰后鎖能自動(dòng)釋放過(guò)期機(jī)制鎖永遠(yuǎn)不釋放業(yè)務(wù)永久卡死防誤刪只能釋放自己持有的鎖唯一標(biāo)識(shí)校驗(yàn)A 釋放掉 B 的鎖互斥被破壞原子性加鎖、解鎖的關(guān)鍵步驟不可分割中間步驟失敗留下臟狀態(tài)可重入/可續(xù)期同線程可重入長(zhǎng)任務(wù)鎖不過(guò)期死鎖或鎖提前失效? 一句話互斥是底線防死鎖是保底防誤刪是禮貌原子性是技術(shù)前提。后面每一代 Redis 實(shí)現(xiàn)都是在補(bǔ)齊這幾條。二、基于 Redis 的實(shí)現(xiàn)演進(jìn)核心章節(jié) 本章是全文核心。記住一個(gè)總覽Redis 分布式鎖的每一代演進(jìn)都是在補(bǔ)上一代的漏洞——1.0 不防死鎖2.0 防死鎖但不防誤刪3.0 防誤刪但不防業(yè)務(wù)沒(méi)跑完鎖先過(guò)期4.0Redisson解決續(xù)期與可重入5.0RedLock試圖解決主從切換丟鎖。2.1 1.0 版本SETNX 手動(dòng) DEL —— 會(huì)死鎖Redis 的SETNXSet if Not eXists天然適合做互斥key 不存在才設(shè)置成功存在就失敗。于是第一版鎖長(zhǎng)這樣# 加鎖成功返回 1失敗返回 0SETNX lock:order1(integer)1# ... 業(yè)務(wù)邏輯 ...DEL lock:order# 釋放鎖問(wèn)題如果業(yè)務(wù)代碼在DEL之前拋異常、進(jìn)程崩潰或機(jī)器宕機(jī)鎖永遠(yuǎn)不會(huì)被刪除其他進(jìn)程永遠(yuǎn)拿不到鎖——直接死鎖。?? 避坑單獨(dú)調(diào)EXPIRE也不行。SETNX和EXPIRE是兩條獨(dú)立命令中間掛了同樣死鎖。兩條命令的非原子性本身就是漏洞。2.2 2.0 版本SET NX EX —— 防死鎖但不防誤刪Redis 2.6.12 給SET命令加了擴(kuò)展參數(shù)把加鎖和設(shè)過(guò)期時(shí)間合并成一條原子命令。Redis 官方文檔明確給出的鎖寫法就是SET lock:order1NX EX30OK# 成功拿到鎖30 秒后自動(dòng)過(guò)期# ... 業(yè)務(wù)邏輯若超過(guò) 30 秒鎖自動(dòng)釋放...DEL lock:orderNXkey 不存在才設(shè)置互斥EX 3030 秒后過(guò)期防死鎖進(jìn)程崩了鎖也會(huì)自動(dòng)釋放。問(wèn)題解鎖時(shí)直接DEL沒(méi)有校驗(yàn)這把鎖是不是我的。典型事故場(chǎng)景——進(jìn)程 A 持鎖業(yè)務(wù)執(zhí)行超過(guò) 30 秒鎖自動(dòng)過(guò)期進(jìn)程 B 拿到鎖開始干活此時(shí) A 終于執(zhí)行完一個(gè)DEL把B 的鎖刪了進(jìn)程 C 又趁機(jī)拿到鎖三個(gè)進(jìn)程同時(shí)進(jìn)臨界區(qū)。?? 避坑鎖過(guò)期時(shí)間設(shè)置是門學(xué)問(wèn)。設(shè)短了業(yè)務(wù)沒(méi)跑完鎖就沒(méi)了設(shè)長(zhǎng)了進(jìn)程崩潰后其他進(jìn)程要干等。2.0 的解法很粗暴讓業(yè)務(wù)必須在鎖過(guò)期前跑完做不到就出問(wèn)題。2.3 3.0 版本value 唯一標(biāo)識(shí) Lua 腳本解鎖 —— 防誤刪核心改進(jìn)兩處加鎖時(shí)給 value 放一個(gè)唯一標(biāo)識(shí)UUID 或雪花 ID鎖是誰(shuí)的一目了然解鎖用 Lua 腳本先比對(duì) value 再刪比對(duì)和刪除在一個(gè)腳本里原子執(zhí)行杜絕先查后刪中間被別人插隊(duì)。# 加鎖value 放本客戶端唯一標(biāo)識(shí)SET lock:order 9f8a2b3c-xxxx NX EX30OK# 解鎖Lua 腳本校驗(yàn) value 一致才 DEL原子操作-- unlock.luaifredis.call(get,KEYS[1])ARGV[1]thenreturnredis.call(del,KEYS[1])elsereturn0end// Java 側(cè)調(diào)用示意jedisStringscriptif redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end;jedis.eval(script,1,lock:order,lockValue);? 成功標(biāo)志A 現(xiàn)在刪不掉 B 的鎖了value 不匹配Lua 返回 0 不刪。仍存在的問(wèn)題業(yè)務(wù)執(zhí)行超過(guò) 30 秒時(shí)鎖照常過(guò)期——value 校驗(yàn)再嚴(yán)格也攔不住鎖提前失效、B 提前進(jìn)入。這要等 Redisson 的看門狗來(lái)解決。2.4 4.0 版本Redisson —— 看門狗自動(dòng)續(xù)期 可重入Redisson是 Java 生態(tài)最主流的 Redis 分布式鎖客戶端庫(kù)它把上面所有補(bǔ)丁做成了開箱即用的封裝。兩個(gè)核心能力① 看門狗Watchdog自動(dòng)續(xù)期用lock()且不指定 leaseTime時(shí)Redisson 啟動(dòng)一個(gè)后臺(tái)定時(shí)任務(wù)默認(rèn)鎖有效期30 秒lockWatchdogTimeout可配置后臺(tái)線程每10 秒30 秒的 1/3檢查一次若當(dāng)前線程仍持有鎖就把過(guò)期時(shí)間刷新回 30 秒只要持有鎖的 JVM 還活著鎖就永遠(yuǎn)不過(guò)期JVM 一旦掛掉看門狗停止續(xù)期鎖在最多 30 秒內(nèi)自動(dòng)釋放——既不會(huì)提前失效也不會(huì)永久死鎖。// Redisson 使用示例RLocklockredisson.getLock(lock:order);lock.lock();// 不傳 leaseTime → 啟用看門狗默認(rèn) 30s 自動(dòng)續(xù)期try{// 業(yè)務(wù)邏輯執(zhí)行多久鎖都在}finally{lock.unlock();// 釋放鎖}?? 注意lock(leaseTime)指定了過(guò)期時(shí)間就不會(huì)啟動(dòng)看門狗。傳了 leaseTime 等于放棄自動(dòng)續(xù)期回到 3.0 的必須在期限內(nèi)跑完模式。② 可重入同一線程可重復(fù)獲取同一把鎖內(nèi)部用哈希結(jié)構(gòu)記錄持有線程 重入次數(shù)解鎖時(shí)計(jì)數(shù)減一為 0 才真正刪除——行為和ReentrantLock一致防止自己鎖自己。仍未解決的問(wèn)題主從切換丟鎖。若 Redis 用主從架構(gòu)客戶端 A 在 master 上加鎖成功master 還沒(méi)來(lái)得及同步到 slave 就宕機(jī)slave 提升為 master——新的 master 上沒(méi)有這把鎖客戶端 B 就能加鎖成功互斥被打破。這是 RedLock 誕生的直接動(dòng)因。2.5 5.0 版本RedLock —— 多節(jié)點(diǎn)半數(shù)加鎖以及那場(chǎng)著名論戰(zhàn)RedLock 思路不再信任單個(gè) Redis 實(shí)例而是向N 個(gè)互相獨(dú)立的 Redis 節(jié)點(diǎn)官方建議 5 個(gè)同時(shí)嘗試加鎖客戶端依次向每個(gè)節(jié)點(diǎn)執(zhí)行SET key value NX EX ttl每個(gè)節(jié)點(diǎn)設(shè)一個(gè)很短的獲取超時(shí)如 50ms避免在不可達(dá)節(jié)點(diǎn)上干等只要在 ttl 內(nèi)成功加鎖的節(jié)點(diǎn)數(shù) ≥ N/2 1如 5 個(gè)中 ≥ 3 個(gè)且總耗時(shí)小于鎖有效期就認(rèn)為加鎖成功鎖的有效期 初始 ttl ? 獲取鎖耗時(shí)失敗則向所有節(jié)點(diǎn)釋放。意圖個(gè)別節(jié)點(diǎn)掛掉、主從切換丟鎖都不影響因?yàn)橹灰鄶?shù)節(jié)點(diǎn)還承認(rèn)這把鎖互斥就成立。這場(chǎng)著名的論戰(zhàn)2016 年 2 月分布式領(lǐng)域名場(chǎng)面Martin Kleppmann《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計(jì)》作者發(fā)表《How to do distributed locking》批評(píng) RedLock核心兩點(diǎn)時(shí)序假設(shè)不成立RedLock 隱含網(wǎng)絡(luò)延遲有界、進(jìn)程暫停有界、時(shí)鐘同步三個(gè)假設(shè)。一次長(zhǎng) GC 暫停比如 35 秒就能讓客戶端以為還持有鎖實(shí)際鎖早已過(guò)期被別人拿走——GC 暫停沒(méi)法用過(guò)期時(shí)間防御沒(méi)有 fencing token鎖應(yīng)該攜帶一個(gè)每次獲取都遞增的令牌讓資源側(cè)校驗(yàn)我這個(gè)操作是不是最新的。RedLock 只有隨機(jī)值資源側(cè)無(wú)法拒絕舊客戶端的遲到寫入。antirezRedis 作者隨即發(fā)文《Is Redlock safe?》辯護(hù)論戰(zhàn)不是安全/不安全的二元問(wèn)題而是鎖的安全模型與使用場(chǎng)景的匹配問(wèn)題對(duì)多數(shù)應(yīng)用RedLock 提供的是合理范圍內(nèi)的實(shí)用安全性。? 雙方罕見(jiàn)的一致如果資源側(cè)支持 fencing token每次操作帶遞增序號(hào)資源側(cè)拒絕舊序號(hào)即使鎖失效也能兜底——這才是終極解。Redis 鎖提供不了這個(gè)數(shù)據(jù)庫(kù)版本號(hào)、ZooKeeper 的遞增 zxid 可以。RedLock 的實(shí)踐結(jié)論務(wù)實(shí)版RedLock 成本高、收益有爭(zhēng)議生產(chǎn)環(huán)境絕大多數(shù)場(chǎng)景不需要上 RedLock更值得做的是鎖 業(yè)務(wù)冪等 資源側(cè)校驗(yàn)的組合。三、常見(jiàn)坑與實(shí)戰(zhàn)建議坑原因解決主從切換丟鎖master 未同步鎖就宕機(jī)新 master 無(wú)鎖RedLock或用讀寫分離下的一致性策略最務(wù)實(shí)的是接受小概率并用冪等兜底GC 停頓致鎖過(guò)期業(yè)務(wù)線程 STW 35s鎖 30s 過(guò)期別的進(jìn)程進(jìn)入看門狗續(xù)期只能緩解不能根治GC 停頓期間續(xù)期線程也停了關(guān)鍵操作配 fencing token 或冪等時(shí)鐘跳躍依賴 TTL 過(guò)期服務(wù)器時(shí)鐘回?fù)軐?dǎo)致鎖提前/延后失效避免依賴系統(tǒng)時(shí)鐘的強(qiáng)一致場(chǎng)景Redis 側(cè)開啟保護(hù)監(jiān)控時(shí)鐘偏差續(xù)期失敗網(wǎng)絡(luò)抖動(dòng)導(dǎo)致看門狗續(xù)期命令失敗Redisson 看門狗有重試監(jiān)控續(xù)期失敗率忘了 finally 解鎖異常路徑不釋放鎖一律try/finally用 Redisson 的lock()時(shí)優(yōu)先 tryLock 帶超時(shí)實(shí)戰(zhàn)建議可照抄能上 Redisson 就別手寫。手寫鎖需要你自己處理 Lua 腳本、續(xù)期、可重入Redisson 全封裝好了踩坑成本遠(yuǎn)低于省下的依賴。加鎖務(wù)必原子解鎖務(wù)必校驗(yàn)SET key value NX EX ttl Lua 校驗(yàn)刪除缺一不可。鎖的粒度越小越好用lock:order:{orderId}而不是lock:order全局鎖避免無(wú)關(guān)請(qǐng)求互相阻塞。設(shè)置合理的 waitTimetryLock(waitTime, leaseTime, TimeUnit)拿不到鎖時(shí)快速失敗/降級(jí)別無(wú)限阻塞。鎖不是銀彈真正確性要求高的場(chǎng)景轉(zhuǎn)賬、庫(kù)存強(qiáng)一致用數(shù)據(jù)庫(kù)行鎖 版本號(hào)或ZooKeeper/etcd別把正確性押在 Redis 鎖上。業(yè)務(wù)冪等是最后防線即使鎖意外失效接口冪等唯一訂單號(hào)防重能兜住重復(fù)執(zhí)行。四、對(duì)比與選型方案互斥實(shí)現(xiàn)防死鎖可靠性復(fù)雜度適用場(chǎng)景手寫 SETNX1.0~3.0Redis SET/Lua過(guò)期時(shí)間低主從切換丟鎖低學(xué)習(xí)、臨時(shí)腳本、非關(guān)鍵路徑Redisson 單實(shí)例Redis Lua 看門狗過(guò)期 自動(dòng)續(xù)期中仍受主從切換影響低絕大多數(shù)業(yè)務(wù)首選RedLock多節(jié)點(diǎn)半數(shù)加鎖過(guò)期 多數(shù)派中有時(shí)序假設(shè)爭(zhēng)議高要求較高的場(chǎng)景需評(píng)估成本ZooKeeper臨時(shí)順序節(jié)點(diǎn) Watch會(huì)話超時(shí)自動(dòng)刪高CP 一致性中正確性敏感、對(duì)性能不極致敏感etcdLease Revision 前綴租約過(guò)期高Raft中云原生/K8s 生態(tài)配置與鎖并存選型規(guī)則結(jié)論前置默認(rèn)選Redisson 單實(shí)例配好主從/哨兵/集群覆蓋 90% 場(chǎng)景正確性敏感、能接受更重依賴 →ZooKeeper / etcd追求極致簡(jiǎn)單、業(yè)務(wù)可容忍偶發(fā)并發(fā) → 手寫 3.0 版原子加鎖 Lua 解鎖RedLock能不上就不上上了也別把它當(dāng)絕對(duì)安全——它解決的是主從丟鎖不是 GC 停頓。五、總結(jié)你真正需要記住的 N 件事分布式鎖解決的痛點(diǎn)是進(jìn)程間互斥單機(jī)的synchronized管不到其他 JVM。一把合格的鎖 互斥 防死鎖 防誤刪 原子性缺一條就出事故。手寫鎖的正確姿勢(shì)加鎖用SET key value NX EX ttl原子解鎖用 Lua 腳本校驗(yàn) value原子兩條缺一不可。演進(jìn)邏輯是補(bǔ)漏洞SETNX 不防死鎖 → SET NX EX 防死鎖 → 唯一標(biāo)識(shí) Lua 防誤刪 → Redisson 看門狗解決續(xù)期 → RedLock 試圖解決主從丟鎖?？撮T狗的本質(zhì)JVM 活著鎖就續(xù)期JVM 掛了鎖最多 30 秒自動(dòng)釋放指定 leaseTime 就沒(méi)有看門狗。RedLock 有先天爭(zhēng)議Martin Kleppmann 批它依賴時(shí)序假設(shè)、沒(méi)有 fencing tokenantirez 辯它是實(shí)用安全。兩者唯一共識(shí)是fencing token / 資源側(cè)校驗(yàn)才是終極兜底。生產(chǎn)選型Redisson 單實(shí)例是默認(rèn)答案正確性敏感上 ZooKeeper/etcdRedLock 謹(jǐn)慎使用。鎖不是萬(wàn)能的業(yè)務(wù)冪等 數(shù)據(jù)庫(kù)版本號(hào) 資源側(cè)校驗(yàn)比任何鎖都可靠。驗(yàn)證清單能解釋為什么微服務(wù)多實(shí)例下 synchronized 失效能手寫 3.0 版鎖原子加鎖 Lua 校驗(yàn)解鎖能說(shuō)清看門狗的觸發(fā)條件不指定 leaseTime 才啟用和默認(rèn)參數(shù)30s 鎖、10s 續(xù)期能說(shuō)清主從切換丟鎖的原理和 RedLock 的應(yīng)對(duì)思路能復(fù)述 Kleppmann 批評(píng) RedLock 的兩點(diǎn)核心論據(jù)時(shí)序假設(shè)、fencing token能在面試中答出生產(chǎn)環(huán)境你用哪個(gè)方案、為什么參考資源Redis 官方文檔Distributed Locks with Redis含 RedLock 分析與實(shí)現(xiàn)清單Redis 官方文檔SET 命令SET key value NX EX官方鎖寫法Redisson 官方文檔Locks and Synchronizers看門狗機(jī)制與lockWatchdogTimeout配置Martin KleppmannHow to do distributed locking2016對(duì) RedLock 的批評(píng)antirezIs Redlock safe?2016對(duì)批評(píng)的回應(yīng)《Redis 設(shè)計(jì)與實(shí)現(xiàn)》《深入理解分布式系統(tǒng)》——分布式鎖與一致性基礎(chǔ)參考