你是不是也遇到過這種詭異現(xiàn)場同一筆訂單的支付回調(diào)被第三方平臺連推三次庫存居然被扣了兩次或者表單只是雙擊了一下提交按鈕數(shù)據(jù)庫里就多出兩條一模一樣的記錄。很多人第一反應(yīng)是加鎖用 synchronized 鎖自己進程里的代碼結(jié)果服務(wù)一上多節(jié)點鎖就形同虛設(shè)了。真正能扛住多實例、多線程并發(fā)場景的我這些年用得最多也最順手的一套組合拳就是Redis setnx UUID。setnx 負責在 Redis 上搶占一個“只有我能通過”的互斥標記UUID 則充當這個標記的持有者身份兩者搭配剛好解決分布式環(huán)境下的互斥、防重、防誤刪問題。這套方案不依賴額外中間件不引入復雜框架只要業(yè)務(wù)里已經(jīng)有 Redis 就能直接落地。特別適合中小團隊、獨立開發(fā)者、以及那些并發(fā)量沒有夸張到需要上 ZooKeeper 的重型業(yè)務(wù)。下面我把這套組合從原理到實戰(zhàn)完整拆開講清楚包括我在生產(chǎn)環(huán)境踩過的那些坑。1. 從一次“并發(fā)事故”說起到底哪里漏了鎖1.1 真實場景庫存扣減、回調(diào)重試、重復提交我最早用上 setnx UUID是因為一個庫存扣減事故。那是電商項目的秒殺模塊服務(wù)端邏輯很簡單收到下單請求后查庫存 - 判斷庫存是否充足 - 扣減庫存 - 生成訂單。單機部署的時候一切正常后來為了平穩(wěn)支撐流量服務(wù)從 1 個節(jié)點擴到了 3 個節(jié)點噩夢就來了。多個線程同時經(jīng)過 Nginx 被分發(fā)到不同節(jié)點它們同時查庫存都發(fā)現(xiàn)還剩下 1 件然后同時執(zhí)行扣減最后庫存變成負數(shù)。更可怕的是訂單表里出現(xiàn)了兩條完全相同的記錄因為兩個請求都認為自己買到了最后一件商品。這就是典型的讀-改-寫競態(tài)問題單機的 synchronized 無能為力因為鎖只在單個 JVM 內(nèi)生效3 個節(jié)點需要的是跨進程的全局鎖。類似的問題在支付場景里更隱蔽。第三方支付平臺為了保證通知可靠送達會按照間隔重試機制反復推送回調(diào)消息比如 15 秒后重試、1 分鐘后重試、15 分鐘后重試。如果業(yè)務(wù)系統(tǒng)沒有做冪等控制每收到一次回調(diào)就更新一次訂單狀態(tài)、加一次賬戶余額用戶賬戶余額就會翻倍增加這種事故上線一次就能讓公司賠到懷疑人生。1.2 單機鎖的邊界與分布式鎖的困境先理清楚一個概念synchronized、ReentrantLock這類 JVM 鎖鎖住的是當前進程內(nèi)的線程它們通過 Monitor 機制保證的是同一 JVM 內(nèi)的線程互斥。一旦服務(wù)拆成多個實例部署每個實例都有自己獨立的 JVM進程 A 的鎖根本管不住進程 B 里的線程。有人可能會說那我用數(shù)據(jù)庫的行鎖不就行了SELECT ... FOR UPDATE確實可以跨進程互斥但問題也明顯鎖由數(shù)據(jù)庫連接持有長時間事務(wù)會占著連接不釋放高并發(fā)下數(shù)據(jù)庫連接池很容易被打滿而且這種方案會把壓力全部引到數(shù)據(jù)庫上數(shù)據(jù)庫通常是整個系統(tǒng)的瓶頸所在不應(yīng)該讓它承擔這種高頻的鎖競爭。分布式鎖需要的是一個所有進程都能訪問到的“公共裁判員”Redis 就是現(xiàn)成的選擇。它的SETNX命令天然具備“沒鍵就寫入有鍵就拒絕”的語義原子性由 Redis 服務(wù)端保證多個客戶端并發(fā)執(zhí)行時不會出現(xiàn)中間狀態(tài)。再加上 Redis 本身就是為高并發(fā)讀寫設(shè)計的性能遠超數(shù)據(jù)庫鎖方案。但只有 setnx 還是不夠。如果所有客戶端都用同一個固定字符串作為鎖的 value解鎖的時候就會出大問題這個后面詳細講。給鎖加上 UUID 作為唯一持有者標識正是這套方案真正的精髓所在。2. 核心武器拆解SETNX 的前世今生與 UUID 的妙用2.1 SETNX 命令到底在做什么SETNX全稱是SET if Not eXists語義非常直白如果 key 不存在就設(shè)置 key 并返回 1如果 key 已經(jīng)存在不進行任何操作并返回 0。# 第一次執(zhí)行key 不存在設(shè)置成功返回 1 SETNX lock:order:10001 request-id-aaa (integer) 1 # 第二次執(zhí)行key 已存在設(shè)置失敗返回 0 SETNX lock:order:10001 request-id-bbb (integer) 0在 Redis 2.6.12 以前使用 SETNX 加鎖存在一個致命問題整個加鎖過程需要分兩步完成先SETNX設(shè)置鎖再用EXPIRE給鎖設(shè)置過期時間。假如執(zhí)行完第一步之后、還沒執(zhí)行第二步的時候進程突然崩潰或 Redis 出現(xiàn)異常這個鎖就永遠不會過期變成一把死鎖后面的請求全部被擋在外面。好在 Redis 2.6.12 之后官方對SET命令做了擴展支持NX、EX、PX等選項把“設(shè)置值 判定不存在 設(shè)置過期時間”合并成了一個原子操作# NX 表示不存在才設(shè)置EX 表示過期時間單位為秒 SET lock:order:10001 request-id-aaa NX EX 30 # 等價寫法PX 表示過期時間單位為毫秒 SET lock:order:10001 request-id-aaa NX PX 30000返回OK表示拿到鎖返回nil表示沒拿到鎖。這里的原子性至關(guān)重要它從根上杜絕了“設(shè)置鎖成功后還沒來得及設(shè)置過期時間就宕機”導致的死鎖問題?，F(xiàn)在無論是 Jedis、Lettuce、Redisson 還是各種語言 SDK底層都已經(jīng)封裝好了這條命令我們調(diào)用setIfAbsent(key, value, timeout, unit)就是在執(zhí)行原子性的 setnx 加鎖操作。2.2 為什么鎖的 value 要用 UUID這就是我反復強調(diào)的重點。很多初學分布式鎖的人會寫出這樣的代碼加鎖時 value 寫死成字符串locked解鎖時直接用DEL lock:order:10001。表面看沒毛病但實際運行一段時間就會出現(xiàn)一種極其隱蔽的 bug。想象一下這個時間線線程 A 通過 setnx 拿到鎖value 是固定的locked業(yè)務(wù)處理比較慢超過了鎖的過期時間 30 秒鎖自動過期了線程 B 通過 setnx 拿到鎖value 同樣是locked線程 A 的業(yè)務(wù)終于執(zhí)行完了執(zhí)行DEL lock:order:10001線程 B 手里的鎖被線程 A 刪掉了此時線程 C 又可以通過 setnx 拿到鎖線程 B 和線程 C 同時執(zhí)行業(yè)務(wù)互斥失效并發(fā)事故重演問題出在鎖的 value 無法區(qū)分持有者是誰所以任何線程都可以刪掉別人的鎖。解決辦法就是給每次加鎖操作生成一個唯一的 UUID作為 value把它當作“身份證”。解鎖之前先取出當前鎖的 value 和自己的 UUID 比對是自己的鎖才刪除不是自己的直接放棄。String requestId UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, 30, TimeUnit.SECONDS);UUID 由時間戳、機器標識、隨機數(shù)等多重因素生成碰撞概率低到可以忽略不計。實際項目中我用過雪花 ID、用當前線程 ID 隨機數(shù)拼接本質(zhì)上都可以只要保證在全局范圍內(nèi)差不多唯一就行。但如果項目里沒有現(xiàn)成的 ID 生成器直接UUID.randomUUID()就是最干凈的選擇不依賴任何外部組件。3. 落地實操基于 setnx UUID 的分布式鎖完整實現(xiàn)3.1 加鎖一行代碼完成原子操作先看一個完整的 Java 實現(xiàn)使用 Spring Boot 的StringRedisTemplate這是最主流的寫法Autowired private StringRedisTemplate redisTemplate; public boolean tryLock(String lockKey, String requestId, long expireSeconds) { // setIfAbsent 對應(yīng) Redis 的 SET key value NX EX seconds return Boolean.TRUE.equals( redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, expireSeconds, TimeUnit.SECONDS) ); }這里我特意強調(diào)使用StringRedisTemplate而不是普通的RedisTemplate因為RedisTemplate默認使用 JDK 序列化寫入 Redis 的 value 會帶著二進制序列化頭后面用 UUID 字符串去比對的時候永遠對不上這個坑我踩過后面排查章節(jié)會細說。加鎖失敗的線程怎么辦兩種策略一種是直接放棄返回“操作失敗請重試”適合秒殺、搶購這類不需要等待的場景另一種是自旋重試用一個循環(huán)加短暫 sleep 反復嘗試獲取鎖適合需要保證任務(wù)最終執(zhí)行的場景比如定時任務(wù)。自旋重試要注意控制最大嘗試次數(shù)和間隔時間避免無效請求把 Redis 打垮。3.2 解鎖Lua 腳本保證原子性解鎖環(huán)節(jié)很多人會偷懶寫成“先 GET 后 DEL”的普通代碼if (requestId.equals(redisTemplate.opsForValue().get(lockKey))) { redisTemplate.delete(lockKey); }這段代碼存在一個競態(tài)窗口。Java 代碼中GET和DELETE是兩個獨立的 Redis 命令中間隔著網(wǎng)絡(luò)往返和 Java 代碼執(zhí)行間隙。假設(shè)線程 A 執(zhí)行完 GET發(fā)現(xiàn) value 確實是自己的 UUID但在執(zhí)行 DELETE 之前鎖恰好過期了線程 B 拿到了鎖線程 A 的 DELETE 依然會把線程 B 的鎖刪掉。誤刪問題繞了一圈又回來了。正確的做法是把校驗和刪除放到同一個 Lua 腳本里讓 Redis 保證整個腳本的原子執(zhí)行-- redis:del_if_equals.lua -- KEYS[1] 是鎖的 keyARGV[1] 是當前線程持有的 UUID if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end對應(yīng)的 Java 調(diào)用private static final String UNLOCK_SCRIPT if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end; public boolean unlock(String lockKey, String requestId) { Long result redisTemplate.execute( new DefaultRedisScript(UNLOCK_SCRIPT, Long.class), List.of(lockKey), requestId ); return Long.valueOf(1L).equals(result); }Lua 腳本在 Redis 中執(zhí)行時整個腳本不會被其他命令插入所以“判斷 value 是否是我的”和“刪除 key”這兩個動作必然是同時完成或同時不完成的從根本上去掉了競態(tài)窗口。3.3 防誤刪的三種寫法對比我把常見的三種解鎖方案整理成一張表方便直觀對比方案實現(xiàn)方式是否防誤刪問題方案 A固定 value DEL key否任何線程都能刪鎖誤刪概率極高方案 BGET 比較 UUID DEL key部分兩步非原子存在競態(tài)窗口方案 CLua 腳本比較 UUID DEL key是無競態(tài)邏輯正確性最高方案 C 是生產(chǎn)環(huán)境的標準做法?？赡茉诘筒l(fā)、純內(nèi)部接口調(diào)用的場景下方案 B 的窗口期幾乎不會出現(xiàn)但它就是一個定時炸彈誰也不知道哪次 Full GC、哪次網(wǎng)絡(luò)抖動就會放大這個窗口。分布式鎖本身就是用來防并發(fā)問題的不能在鎖的收尾環(huán)節(jié)自己再制造一個并發(fā)問題。3.4 多種語言實現(xiàn)參考不同技術(shù)棧的原理完全一樣這里再補兩個常見的語言版本。Python 版本使用 redis-pyimport redis import uuid r redis.Redis(host127.0.0.1, port6379, db0) def acquire_lock(lock_key, expire_seconds30): request_id str(uuid.uuid4()) # SET key value NX EX seconds ok r.set(lock_key, request_id, nxTrue, exexpire_seconds) return ok, request_id def release_lock(lock_key, request_id): # Lua 腳本保證“比對 刪除”原子執(zhí)行 script if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end return r.eval(script, 1, lock_key, request_id) 1Go 版本使用 go-redisimport ( context github.com/redis/go-redis/v9 github.com/google/uuid time ) // AcquireLock 加鎖成功返回 lockToken失敗返回空字符串 func AcquireLock(ctx context.Context, rdb *redis.Client, key string, ttl time.Duration) string { token : uuid.New().String() ok, err : rdb.SetNX(ctx, key, token, ttl).Result() if err ! nil || !ok { return } return token } // ReleaseLock 使用 Lua 腳本解鎖 func ReleaseLock(ctx context.Context, rdb *redis.Client, key, token string) error { script : if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end return rdb.Eval(ctx, script, []string{key}, token).Err() }不管用哪種語言核心就是四件事加鎖用SET NX EX原子操作、鎖標識用 UUID、解鎖用 Lua 腳本做校驗刪除、業(yè)務(wù)邏輯包在 try-finally 結(jié)構(gòu)中確保最后一定釋放鎖。4. 業(yè)務(wù)拓展setnx UUID 做冪等防重與唯一單號4.1 冪等鍵設(shè)計UUID 當請求的唯一身份證分布式鎖只是 setnx UUID 的一種用法實際上這套組合還有一個非常高頻的場景接口冪等防重。什么是冪等同一個請求無論被提交一次還是十次對系統(tǒng)產(chǎn)生的影響都只有一次。放到前面支付回調(diào)解的例子來說第三方支付平臺會按固定策略重試推送回調(diào)業(yè)務(wù)接口必須保證第一條回調(diào)來了正常處理后續(xù)重試的回調(diào)來了不做重復處理。實現(xiàn)思路很簡單?？蛻舳嗽诎l(fā)起請求時生成一個 UUID 放在請求頭里作為requestId服務(wù)端收到請求后先執(zhí)行SET requestId 1 NX EX 60。如果設(shè)置成功說明這是第一次收到這個請求放行執(zhí)行后續(xù)業(yè)務(wù)如果設(shè)置失敗說明這個請求已經(jīng)處理過直接返回之前的處理結(jié)果或一個標識“重復請求”。String requestId request.getHeader(X-Request-Id); // 客戶端傳入 if (requestId null || requestId.isEmpty()) { requestId UUID.randomUUID().toString(); } Boolean first redisTemplate.opsForValue() .setIfAbsent(idem: requestId, 1, 60, TimeUnit.SECONDS); if (!Boolean.TRUE.equals(first)) { // 重復請求直接返回 return Result.repeat(); } // 正常執(zhí)行業(yè)務(wù)邏輯這里 UUID 的價值就體現(xiàn)得很充分客戶端不用請求服務(wù)端生成唯一編號省一次網(wǎng)絡(luò)開銷也不會像自增 ID 那樣在不同的服務(wù)實例上有生成沖突更不需要依賴消息隊列的順序保證。4.2 冪等防重和分布式鎖的異同順便把這兩個概念對比清楚很多讀者會把它們搞混。分布式鎖的精髓是“同一時刻只能有一個線程執(zhí)行”強調(diào)的是并發(fā)互斥。A、B 兩個請求同時到達A 拿到鎖執(zhí)行B 必須等待或失敗鎖釋放后 B 才能進入。冪等防重的精髓是“同一個標識只能成功處理一次”強調(diào)的是時間維度上的去重。A、B 兩個請求是同一筆訂單的兩次回調(diào)它們不是并發(fā)到達的而是先后到達的系統(tǒng)要識別出它們其實是一回事。兩者本質(zhì)共用了一套“互斥 唯一標識”的機制差別主要在于鎖的生命周期和粒度。分布式鎖通常根據(jù)業(yè)務(wù)執(zhí)行時間設(shè)置較短的過期時間執(zhí)行完立刻釋放冪等鍵通常要覆蓋整個重試窗口比如設(shè)置 5 分鐘甚至 24 小時確保所有重試請求到達時都還處于有效期內(nèi)。實際項目里這兩個經(jīng)常組合使用。比如下單接口先用 UUID 冪等鍵擋住重復提交再用 setnx 分布式鎖保護庫存扣減這個臨界區(qū)兩層配合既擋重試又防并發(fā)。5. 容易踩的坑與高頻報錯排查實錄5.1 鎖提前過期導致業(yè)務(wù)沒鎖住怎么破這是 setnx UUID 方案最大的短板鎖的過期時間到了但業(yè)務(wù)還沒執(zhí)行完。鎖一過期其他線程就能拿鎖進來前一個線程的業(yè)務(wù)還在跑臨界區(qū)保護名存實亡。應(yīng)對思路有三個。第一給鎖設(shè)置一個合理的、偏長的過期時間。前提是你對業(yè)務(wù)的最長執(zhí)行時間有清晰預期比如批量導出任務(wù)估算最慢可能 20 秒就把過期時間設(shè)成 30 秒到 60 秒留足余量。第二業(yè)務(wù)內(nèi)部主動續(xù)期寫一個守護線程定時檢查如果業(yè)務(wù)還沒結(jié)束就用 Lua 腳本給鎖續(xù)期相當于給鎖“續(xù)命”。第三引入 Redisson 這類成熟框架它內(nèi)置了“看門狗”機制默認加鎖后會自動續(xù)期業(yè)務(wù)結(jié)束前鎖不會提前釋放。對于大多數(shù)不追求極致性能的業(yè)務(wù)我建議先做好第一條和第二條最簡單的方式是把過期時間設(shè)得足夠大同時在 finally 塊里確保釋放鎖。分布式鎖的過期時間寧可大一點也不要因為設(shè)置太小導致并發(fā)穿透。5.2 誤刪他人鎖的根源與腳本原子性前面原理部分講過了再給一個非常具體的排查案例。某天線上突然出現(xiàn)重復扣款訂單日志里看到兩個線程都執(zhí)行了臨界區(qū)代碼但明明加鎖了。查到最后發(fā)現(xiàn)項目里解鎖代碼用的是先 GET 再 DEL 的兩步寫法一個執(zhí)行慢的線程把自己的鎖等過期了另一個線程進來拿到鎖第一個線程業(yè)務(wù)結(jié)束執(zhí)行 DEL把第二個線程的鎖刪了。修復方案就是用 Lua 腳本把“值比對”和“key 刪除”做成一個原子操作。這再次印證了分布式鎖的錯誤絕大多數(shù)不是加鎖出錯而是解鎖環(huán)節(jié)出錯。5.3 Redis 主從切換導致鎖丟失的爭議圍繞 Redis 分布式鎖最大的爭議之一是主從架構(gòu)下的鎖丟失問題。Redis 主從復制默認是異步的客戶端在主節(jié)點寫入鎖 key 成功后返回但這個 key 還沒同步到從節(jié)點主節(jié)點就掛了哨兵把某個從節(jié)點提升為新主節(jié)點。此時新主節(jié)點上沒有這把鎖的數(shù)據(jù)其他客戶端就能再次加鎖成功互斥失效。對這個問題Redis 官方提出了 RedLock 算法向多個獨立的 Redis 節(jié)點依次加鎖超過半數(shù)成功才算加鎖成功。但 RedLock 本身爭議也很大多位分布式系統(tǒng)專家都指出過它在某些時鐘場景下依然不安全。以我的實際經(jīng)驗對于絕大多數(shù)業(yè)務(wù)系統(tǒng)不需要走到 RedLock 這一步。除非你面臨的條件非?？量蘎edis 節(jié)點故障概率高、同時并發(fā)量巨大、鎖失效會引發(fā)嚴重資損事故。這種情況下更應(yīng)該考慮引入 Redisson它支持 RedLock 封裝還支持故障轉(zhuǎn)移時的鎖保護策略。普通項目老老實實用單節(jié)點 Redis 加哨兵高可用就夠了鎖的過期時間保守設(shè)置出問題的概率遠比想象中低。5.4 RedisCommandTimeoutException 超時問題的排查思路很多新手第一次在生產(chǎn)環(huán)境跑這個方案會遇到這么一行報錯io.lettuce.core.RedisCommandTimeoutException: Command timed out after 10 second(s)注意這次報錯的是 Redis 客戶端命令超時不是業(yè)務(wù)鎖邏輯本身的錯誤。常見原因無非以下幾種第一網(wǎng)絡(luò)抖動或 Redis 服務(wù)端阻塞。Redis 是單線程模型如果有一條慢查詢比如KEYS *命令掃描全庫、大集合的SMEMBERS卡住了后續(xù)所有命令都會排隊等待超過客戶端超時閾值就拋異常。排查時先redis-cli -h 127.0.0.1 -p 6379 ping看連通性再用SLOWLOG GET 10查看慢查詢記錄。第二Lettuce 客戶端默認超時設(shè)置不合理。Spring Boot 2.x 默認使用 Lettuce 客戶端底層基于 Netty默認超時時間不一定適合你的場景。在配置里顯式調(diào)優(yōu)spring: data: redis: timeout: 5s lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0 shutdown-timeout: 100ms第三連接池被打滿。并發(fā)量大而連接池上限設(shè)得小客戶端線程排隊等連接超過超時時間?？梢哉{(diào)大max-active同時檢查業(yè)務(wù)代碼有沒有及時釋放連接。Lettuce 本身是線程安全的正常情況下一個連接實例能并發(fā)處理很多請求但如果開啟了共享連接配置不當也可能出現(xiàn)連接饑餓。第四大 key 的刪除操作導致 Redis 阻塞。刪除一個包含數(shù)百萬元素的 hash 或 list 時DEL命令是同步阻塞的期間所有請求都會卡住。正確的做法是使用UNLINK命令異步刪除或者對大 key 分批裁剪。5.5 RedisTemplate 序列化導致 UUID 比對失敗的坑一個非常隱蔽的坑Spring Boot 項目里同時注入RedisTemplateString, String然后寫入字符串 UUIDGET 出來比對的時候發(fā)現(xiàn)值不一樣鎖刪除永遠失敗。原因在于默認的RedisTemplate使用 JDK 序列化器寫入 Redis 的實際內(nèi)容是經(jīng)過序列化處理后的二進制數(shù)據(jù)而不是純字符串。你存進去的是d5a9b7f2-8c31-4e43-a1d1-55c9c4e1a2b3存到 Redis 里的可能是一長串帶類名信息的二進制內(nèi)容再 GET 出來自然對不上。解決方案就是統(tǒng)一使用StringRedisTemplate它內(nèi)部已經(jīng)幫我們把 key 和 value 的序列化器都配置成了StringRedisSerializer存進去的是普通字符串取出來也是普通字符串。如果你的項目必須使用自定義的RedisTemplate記得顯式設(shè)置序列化器Bean public RedisTemplateString, String redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, String template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer stringRedisSerializer new StringRedisSerializer(); template.setKeySerializer(stringRedisSerializer); template.setValueSerializer(stringRedisSerializer); template.setHashKeySerializer(stringRedisSerializer); template.setHashValueSerializer(stringRedisSerializer); template.afterPropertiesSet(); return template; }這個坑最讓人頭疼的是它“偶爾正常、偶爾異?！辈l(fā)高的時候誤刪鎖的 bug 才會被放大排查成本很高。6. 我在生產(chǎn)環(huán)境用這套方案的習慣和幾個建議這套 setnx UUID 組合我用了很多年雖然 Redisson 這類框架已經(jīng)能提供更完善的開箱即用能力但很多場景下我依然傾向于手寫這套輕量方案。原因很簡單依賴最少、邏輯透明、出了問題能一眼看穿。在鎖的 key 命名上我習慣統(tǒng)一用lock:前綴加業(yè)務(wù)域再加具體業(yè)務(wù)標識比如lock:order:10001。這樣在 Redis 里一眼就能看到當前有哪些鎖排查死鎖問題時非常方便。過期時間我一般按業(yè)務(wù)最慢耗時的 3 倍來設(shè)置寧可讓鎖多占一會兒也不能讓它在業(yè)務(wù)結(jié)束前失效。加鎖失敗的線程我傾向直接返回失敗結(jié)果不做大量自旋因為自旋會放大對 Redis 的請求壓力。冪等鍵的 key 我習慣用idem:前綴和鎖明確區(qū)分開。過期時間根據(jù)重試窗口來定一般至少覆蓋第三方平臺的最大重試間隔。如果對接的支付通道重試策略是 15 分鐘就把冪等鍵過期時間設(shè)成 30 分鐘以上。最后再分享一個我踩過坑后養(yǎng)成的習慣加鎖和解鎖的日志必須打印出來包含 key 和 UUID。線上出問題回查日志時你可以完整還原哪個線程在什么時間拿到了鎖、什么時間釋放了鎖、是否出現(xiàn)了誤刪。這套方案的邏輯本身不復雜真正難的是在復雜鏈路里快速定位問題而完善的日志是所有排查手段的基礎(chǔ)比任何監(jiān)控面板都直接。