這一講想聊一個后端老生常談、但一聊就吵翻天的東西緩存一致性。尤其是那個被無數(shù)人提過又嫌棄過的“延遲雙刪”策略。我最早接觸它是在一個電商中臺項目里商品詳情接口扛不住壓力Redis緩存一上QPS是上去了但沒過多久就出現(xiàn)了“改價不生效”“庫存更新了頁面還是舊數(shù)據(jù)”的投訴單半夜被叫起來查數(shù)據(jù)發(fā)現(xiàn)緩存里是舊值數(shù)據(jù)庫里是新值兩邊誰也沒比誰理直氣壯。后來把延遲雙刪、消息隊列補償、版本號標記、訂閱Binlog這幾條路都試了一遍才算理清楚什么場景該上什么方案。如果你正在被緩存一致性折騰或者面試前想把這塊補明白又或者剛把緩存引入系統(tǒng)還沒踩坑這篇文章值得看完。我會把延遲雙刪的原理、代碼怎么落、坑在哪、延遲時間到底怎么估、以及它和別的方案的關(guān)系講透不繞彎子。1. 緩存一致性問題的本質(zhì)1.1 緩存和數(shù)據(jù)庫是怎么開始“打架”的先別急著聊雙刪先搞明白一個事緩存和數(shù)據(jù)庫為什么會對不上。緩存本質(zhì)上是數(shù)據(jù)庫結(jié)果的“快照副本”它和數(shù)據(jù)庫是兩個獨立的存儲系統(tǒng)沒有事務約束沒有強一致協(xié)議。只要存在兩條獨立的寫路徑就一定會出現(xiàn)數(shù)據(jù)不一致的時間窗口。最常見的沖突發(fā)生在兩個動作之間一個是更新數(shù)據(jù)庫的寫請求一個是把數(shù)據(jù)庫內(nèi)容回填到緩存的讀請求。這倆如果并發(fā)發(fā)生節(jié)奏稍微錯開一點就會造成“數(shù)據(jù)庫已經(jīng)是新值緩存里卻回填了舊內(nèi)容”的經(jīng)典事故。我拆一個具體時間線給你看時間 T1寫請求 A 更新數(shù)據(jù)庫把商品價格改成 100 元。時間 T2讀請求 B 在數(shù)據(jù)庫里拿到舊數(shù)據(jù) 80 元此時 A 還沒提交或者 B 的查詢快照是舊的。時間 T3寫請求 A 提交成功數(shù)據(jù)庫里是 100 元。時間 T4讀請求 B 把 80 元寫入緩存。時間 T5后續(xù)所有讀請求打到緩存上看到的都是 80 元但數(shù)據(jù)庫里是 100 元數(shù)據(jù)不一致。直到緩存過期這個問題才被兜底消除。問題就出在 T3 和 T4 的并發(fā)窗口。如果不做任何緩存清理窗口有多長緩存就有多久是臟數(shù)據(jù)。在高并發(fā)下T2 和 T4 之間的距離可能只有幾毫秒但這幾毫秒里如果涌進來大量讀流量臟數(shù)據(jù)就會被大規(guī)模復制到緩存里影響面遠比單次讀大。1.2 先更新庫還是先操作緩存其實都走不通很多人第一反應是調(diào)整操作順序。那我們把兩條主線都走一遍?！跋雀聰?shù)據(jù)庫再更新緩存”這條路問題非常明顯。兩個寫請求并發(fā)時后寫緩存的請求可能覆蓋前一個請求的新值。比如線程 A 把數(shù)據(jù)庫更新成 10線程 B 把數(shù)據(jù)庫更新成 20此時線程 B 先更新緩存成功線程 A 再更新緩存緩存里最終是 10但數(shù)據(jù)庫是最新值 20緩存被舊事務覆蓋一致性直接崩?！跋雀戮彺嬖俑聰?shù)據(jù)庫”更不靠譜緩存一旦更新成功、數(shù)據(jù)庫執(zhí)行失敗緩存里就是一個數(shù)據(jù)庫中不存在的數(shù)據(jù)讀到的基本就是幻覺數(shù)據(jù)?！跋雀聰?shù)據(jù)庫再刪除緩存”這就是經(jīng)典的 Cache Aside 模式。它比前兩條路都安全因為刪除緩存的操作天然是冪等的刪除總比覆蓋安全。但讀者會問刪除緩存就能保證一致嗎答案是不能因為還要處理讀請求在刪除之前把舊數(shù)據(jù)回填進緩存的并發(fā)窗口就是我上面畫的 T2 到 T4 那段。這里順帶說一句網(wǎng)上有人爭論“更新緩存”和“刪除緩存”哪個好。從一致性角度我強烈建議你刪緩存而不是更新緩存。更新緩存存在兩個問題一是讀請求回填的舊值可能覆蓋你更新的新值二是一些復雜的緩存結(jié)構(gòu)比如 Hash、ZSet更新成本高很容易寫出并行覆蓋 Bug。刪除緩存雖然會造成一次緩存 miss但它是冪等操作配合重試機制收斂性要比更新緩存好得多。1.3 為什么單純加過期時間救不了你有人會覺得反正緩存都有過期時間不一致只是暫時的忍忍就過了。這話在非核心業(yè)務上說得通但核心數(shù)據(jù)在緩存過期之前可能已經(jīng)被大量讀到了。一旦臟數(shù)據(jù)被復制到緩存哪怕過期時間是 30 秒30 秒內(nèi)所有用戶請求都會讀到錯誤數(shù)據(jù)。在電商大促場景下300 個 QPS 持續(xù) 30 秒臟數(shù)據(jù)影響面就是 9000 個請求這還沒算緩存 TTL 被續(xù)期的雪上加霜。所以緩存一致性方案的核心目標是盡量縮短臟數(shù)據(jù)的存在時間并且在無法完全消除的時間窗口內(nèi)提高快速矯正的概率。延遲雙刪就是在這個思路上做文章的。2. 延遲雙刪的核心原理2.1 雙刪方案的兩個階段拆解延遲雙刪字面意思就是刪兩次第二次延遲后再刪。它的核心思路是基于對并發(fā)時序的補償。第一次刪除發(fā)生在數(shù)據(jù)庫更新之前目的是清掉上一次讀請求可能回填的舊緩存。第二次刪除發(fā)生在數(shù)據(jù)庫更新之后延遲一小段時間目的是把那個時間窗口內(nèi)可能回填進去的舊值再次清掉。第二次刪除的目標不是普通讀請求而是針對“舊值已經(jīng)被回填”的破壞性窗口。整個流程完整走一遍是這樣的寫請求進入服務。先執(zhí)行緩存刪除第一次刪除。再執(zhí)行數(shù)據(jù)庫更新。開始計時等待一個延遲時間。延遲結(jié)束后再執(zhí)行一次緩存刪除第二次刪除。第二步的刪緩存是為了給后續(xù)讀請求一個空窗口讓它們?nèi)?shù)據(jù)庫讀新值。第三步更新數(shù)據(jù)庫后讀請求在延遲窗口內(nèi)依舊可能讀到舊值并寫回緩存所以第四步的第二次刪除是關(guān)鍵補償。但這里有個疑問為什么不是更新數(shù)據(jù)庫后立刻刪而是要延遲原因在于一個讀請求從數(shù)據(jù)庫讀取成功、到把數(shù)據(jù)寫回緩存這個過程是有 IO 時間成本的。如果更新數(shù)據(jù)庫后在 1 毫秒內(nèi)立即刪除那個正在執(zhí)行“數(shù)據(jù)庫讀取-網(wǎng)絡傳輸-緩存寫入”的讀請求很可能正好在第二次刪除之后把舊值寫進緩存刪除動作就白做了。延遲的目的就是讓這個并發(fā)窗口內(nèi)的“最后寫入者”把臟數(shù)據(jù)寫完之后再去清除它。2.2 延遲時間到底怎么估算延遲時間定多少是延遲雙刪方案里最需要動腦子的一步。它不是拍腦袋定一個 500ms 就行而是要根據(jù)具體的業(yè)務來算。要覆蓋的并發(fā)窗口長度由兩部分組成讀請求從數(shù)據(jù)庫讀取數(shù)據(jù)到寫回緩存的總耗時加上一個安全裕度。讀請求的耗時包括網(wǎng)絡傳輸時間、數(shù)據(jù)庫查詢時間、緩存寫入時間。在大部分內(nèi)部服務架構(gòu)中這個耗時一般不會超過幾十毫秒但網(wǎng)絡出現(xiàn)抖動、數(shù)據(jù)庫慢查詢出現(xiàn)時會顯著放大。我一般會給一個公式參考延遲時間 ≥ 一次完整讀請求的耗時時長峰值 網(wǎng)絡抖動安全閾值舉個例子你的服務讀請求平均耗時是 30ms峰值是 100ms那延遲時間至少是 100ms 加上 200-300ms 的余量取 500ms 左右是比較穩(wěn)妥的。延遲時間太短等于沒刪對并發(fā)窗口的覆蓋不夠延遲時間太長寫請求的響應時間會被拖慢。注意延遲的時間是在更新數(shù)據(jù)庫之后、返回寫請求之前加的一段阻塞等待這段等待會直接拖長寫接口的響應時間對延遲敏感的業(yè)務來說這是個明顯代價。我也見過一種高吞吐的設計把第二次刪除動作挪到異步線程池去執(zhí)行寫請求更新數(shù)據(jù)庫后立刻返回由后臺異步任務延遲 500ms 后再刪緩存。這樣寫請求 RT 不會被延遲拖累但異步任務和寫請求的生命周期解綁了需要額外處理任務失敗、應用重啟丟任務的問題工程復雜度有所增加。2.3 為什么“先刪一次再刪兩次”存在邊界問題不是所有場景都適合雙刪。雙刪解決的是“讀寫并發(fā)時序交錯”的緩存一致性問題但在極端并發(fā)下雙刪也無法做到百分百保證一致。舉個例子如果讀請求特別慢慢到超過了延遲時間那么在第二次刪除之后它依然可能把舊值寫回緩存造成新一輪臟數(shù)據(jù)。這種場景下你需要額外的手段去兜底比如給緩存加一個主動標記版本的機制。所以嚴格的講延遲雙刪不是一個百分之百強一致的方案而是一個把不一致概率降到很低的工程方案。這個認知很重要。網(wǎng)上有些文章把雙刪吹成了“緩存一致性銀彈”實際做過的人都知道它只是一個概率收斂方案能保障的是在絕大多數(shù)常規(guī)并發(fā)時序下一致。這也就是為什么我在后面會講到生產(chǎn)環(huán)境往往需要雙刪配合重試、版本號、Binlog 訂閱來組合使用。3. 延遲雙刪的工程實現(xiàn)方案3.1 一個最小可落地的同步實現(xiàn)最小可落地的方案不引入額外中間件直接在一個業(yè)務方法里寫同步邏輯。我用一個 Java 實現(xiàn)的示例來講這個代碼邏輯十分直觀。Service public class ProductServiceImpl implements ProductService { Autowired private StringRedisTemplate redisTemplate; Autowired private JdbcTemplate jdbcTemplate; private static final String PRODUCT_CACHE_KEY product:detail:; private static final long DELETE_RETRY_DELAY_MS 500; Transactional public void updateProductPrice(Long productId, BigDecimal newPrice) { String cacheKey PRODUCT_CACHE_KEY productId; // 第一次刪除清掉舊緩存讓后續(xù)讀請求重新加載 redisTemplate.delete(cacheKey); // 更新數(shù)據(jù)庫 jdbcTemplate.update(UPDATE product SET price ? WHERE id ?, newPrice, productId); // 延后再刪一次覆蓋讀請求并發(fā)回填臟數(shù)據(jù)窗口 new Thread(() - { try { Thread.sleep(DELETE_RETRY_DELAY_MS); redisTemplate.delete(cacheKey); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }).start(); } }這個實現(xiàn)非常簡陋但可以幫你快速理解雙刪的骨架。代碼里有兩個明顯問題第一每次更新都創(chuàng)建新線程在高并發(fā)下線程開銷很大第二沒有處理刪除失敗的情況。這只是教學演示真正落生產(chǎn)環(huán)境至少要做線程池化和失敗重試。3.2 生產(chǎn)級實現(xiàn)線程池 延時補償生產(chǎn)環(huán)境的核心原則是能用現(xiàn)成的線程池絕不自己 new Thread刪除操作要有重試補償機制。寫請求側(cè)把第二次刪除的任務提交到定時線程池由線程池統(tǒng)一延遲執(zhí)行避免頻繁創(chuàng)建線程。使用 ScheduledExecutorService 可以很方便地做延遲調(diào)度。下面是一個簡單的生產(chǎn)級改造示例Component public class CacheDelayedRemover { private static final ScheduledExecutorService SCHEDULER Executors.newScheduledThreadPool(10, r - { Thread t new Thread(r, cache-delayed-remover); t.setDaemon(true); return t; }); private final StringRedisTemplate redisTemplate; public CacheDelayedRemover(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } public void submitDeleteTask(String cacheKey, long delayMs) { SCHEDULER.schedule(() - { try { redisTemplate.delete(cacheKey); } catch (Exception e) { // 刪除失敗進入重試補償邏輯 handleRetry(cacheKey); } }, delayMs, TimeUnit.MILLISECONDS); } private void handleRetry(String cacheKey) { // 簡單重試最多重試3次每次間隔200ms for (int i 0; i 3; i) { try { Thread.sleep(200); Boolean deleted redisTemplate.delete(cacheKey); if (Boolean.TRUE.equals(deleted)) { return; } } catch (Exception ex) { Thread.currentThread().interrupt(); } } // 如果重試3次仍失敗發(fā)告警或者投遞到死信隊列人工處理 log.warn(cache delete failed after retries, key: {}, cacheKey); } }與之配套寫請求方可以改成異步拋出刪除任務讓寫接口快速返回。我把最核心的一點放在這里延遲刪除的任務本質(zhì)上是一個“最終一致性補償任務”它可能丟失所以一定要搭配告警或者消息隊列做閉環(huán)。如果你是小型業(yè)務系統(tǒng)用調(diào)度線程池重試 3 次就夠了中型以上團隊建議從延時隊列或消息隊列這條路走。3.3 結(jié)合 Redis 的偽刪除與版本防競爭延遲雙刪也可以考慮一些“非主流”但有效的變體。比如不直接刪除緩存而是去修改緩存里的占位標記或者執(zhí)行“偽刪除”把 value 變成空結(jié)構(gòu)讓業(yè)務讀取時主動感知“數(shù)據(jù)已變更”。這個思路往往能降低緩存重建時的并發(fā)沖擊。原型做法是第二次刪除成功后設置一個短暫的邏輯過期標記比如 1 秒的空緩存。在標記存在期間讀請求不直接把結(jié)果寫回緩存而是排隊等待寫請求的通知或者返回默認值。這相當于把“雙刪”變成了“SB 隨刪隨回”的模式對讀多寫少但有強提示需求的業(yè)務很管用。不過我必須提醒你這種變體引入了一個新的復雜度同一緩存 key 的讀寫雙方需要協(xié)商一個“占位標記”的語義而且標記本身也需要清理。如果標記沒清干凈后續(xù)正常讀流量也會被拖累。所以對于常規(guī)系統(tǒng)我建議還是走標準雙刪不要一上來就搞標操作。4. 延遲雙刪在真實業(yè)務中的坑與優(yōu)化4.1 延遲時間是拍腦袋定的“延遲時間不用太精確吧”這是我聽過最多的話。延遲時間的設定直接決定方案的有效性拍腦袋定 500ms 不是不行但要驗證。我的建議是先根據(jù)日志統(tǒng)計出讀請求耗時 P99 和 P999 值。如果 P99 是 50msP999 是 300ms那延遲時間就要往 300ms 以上走。最好再加一半的余量。我實際遇到過一個情況表數(shù)據(jù)量一大MySQL 偶爾出現(xiàn) 1 秒以上的慢查詢讀請求的耗時直接被拉爆原來定的 500ms 延遲完全不夠用第二次刪除之后舊值還會被慢讀線程回填。后來只能把延遲調(diào)到 1500ms代價是寫請求 RT 變差。用異步化改造后寫接口 RT 才恢復正常。所以延遲時間必須基于峰值來定而不是平均值。4.2 刪除緩存失敗怎么辦延遲雙刪最容易被忽略的隱藏問題是第二次刪除失敗。Redis 操作雖然是 O(1) 級別但網(wǎng)絡抖動、連接池耗盡、key 被誤刪、Redis 主從切換都可能造成刪除失敗。一旦第二次刪除失敗緩存里殘留的臟數(shù)據(jù)就會緩存到 TTL 到期。解決思路有三條路一是給刪除操作加重試機制這是必須的內(nèi)存里的簡單重試、對賬任務都可以。二是把刪除失敗的任務落到本地數(shù)據(jù)庫一張待刪表由清掃任務輪詢重試直到成功。三是訂閱 Redis 的 key 失效事件對“應刪但沒刪掉”的 key 進行兜底清理。第一條最簡單工程上足夠覆蓋絕大多數(shù)場景第二條成本中等能保證最終刪除第三條依賴 Redis 的事件通知機制配置和運維成本略高?？磮F隊規(guī)模選擇即可。4.3 分布式環(huán)境下的并發(fā)放大問題延遲雙刪在處理單個緩存 write read 并發(fā)時表現(xiàn)不錯但多個線程同時更新同一個 key 時情況會變得復雜。舉例線程 A 和線程 B 同時并發(fā)更新商品價格分別更新為 10 和 20。假設線程 A 先刪緩存、再更庫為 10線程 B 后刪緩存、再更庫為 20。由于兩次更新交替緩存可能在某個時間點被線程 A 或 B 的延遲刪除反復清掉也可能在 B 第二次刪除前被某個讀請求用 10 塊的新數(shù)據(jù)回填結(jié)果庫里是 20緩存里是 10又臟了。這種多寫并發(fā)場景光靠雙刪是壓不住的。需要引入“版本號”機制讓緩存值攜帶數(shù)據(jù)庫的版本標識讀請求發(fā)現(xiàn)版本不一致主動丟棄數(shù)據(jù)。版本號方案我會在下一節(jié)展開講這里先留個鉤子延遲雙刪擅長處理“讀寫并發(fā)”不擅長處理“多寫并發(fā)”后者需要更強的手段。4.4 緩存擊穿和緩存雪崩風險延遲雙刪每次都會導致緩存 miss讀請求會直接打到數(shù)據(jù)庫。如果一個熱點 key 被頻繁更新延遲雙刪會頻繁刪緩存大量讀流量瞬間涌入數(shù)據(jù)庫極可能導致數(shù)據(jù)庫連接被打滿這就是緩存擊穿。要降低風險可以把第二次刪除之后的緩存重建過程做一個保護。常見做法是在緩存重建時加互斥鎖同一時刻只有一個線程去數(shù)據(jù)庫加載數(shù)據(jù)并回填緩存其他線程短暫等待或返回舊值。這個做法和延遲雙刪是天然搭檔一個負責清理一個負責防擊穿組合在一起才是一個比較完整的生產(chǎn)級方案。4.5 閾值與監(jiān)控你怎么知道方案有效交付一套延遲雙刪機制不能只寫代碼就完了還要有可觀測性。我建議從三個維度打日志和指標第一次刪除的耗時、成功率和刪除時是否命中 key。第二次刪除的延遲執(zhí)行隊列積壓量、執(zhí)行成功率和重試次數(shù)。數(shù)據(jù)庫更新完成到第二次刪除完成的時間間隔分布。如果發(fā)現(xiàn)第二次刪除成功率長期低于 99%先檢查 Redis 連接和超時時間。如果發(fā)現(xiàn)刪除隊列積壓超過閾值檢查線程池大小和調(diào)度頻率。緩存一致性問題最怕黑盒一定要把每次刪除動作的日志打出來出了事才有據(jù)可查。5. 延遲雙刪的進階替代與結(jié)合方案5.1 Cache Aside 延遲雙刪的關(guān)系先明確一個概念延遲雙刪不是一個獨立的架構(gòu)模式它更接近 Cache Aside 模式的一種補償增強。Cache Aside 標準套路是先更新數(shù)據(jù)庫再刪除緩存而延遲雙刪在刪除緩存前面加了預處理在更新數(shù)據(jù)庫后面加了延后補償。從系統(tǒng)演進的角度它是在 Cache Aside 方案上的一個高可用改進。如果你團隊里有人問“我們已經(jīng)在用 Cache Aside還需要延遲雙刪嗎”我的建議是如果你們的業(yè)務允許偶發(fā)一秒內(nèi)的緩存不一致Cache Aside 夠用如果業(yè)務要求不一致窗口盡可能短而你們又不想上更重的組件就值得引入延遲雙刪作為增強。5.2 基于消息隊列的最終一致性方案比延遲雙刪更重但更可靠的方式是把緩存刪除動作投遞到消息隊列由消費者在拿到消息后異步刪除緩存。這樣寫請求不用阻塞等待延遲時間消息隊列天然提供了可靠投遞、重試機制。流程示例寫請求更新數(shù)據(jù)庫成功后發(fā)送一條“刪除緩存”的消息。消息消費者收到消息后延遲一小段時間可以用 MQ 的延遲消息能力或者消費者內(nèi) sleep再執(zhí)行 Redis 刪除。如果刪除失敗MQ 的重試機制會自動重投。這種方案的優(yōu)點是把“延遲刪”從內(nèi)存里挪到了消息隊列中可靠性高。缺點是需要額外引入 MQ 組件運維和部署成本上升而且并非所有 MQ 都支持延遲消息開源版 RocketMQ 需要安裝延遲插件Kafka 原生不支持需要自己做時間輪。5.3 基于 Binlog 訂閱的旁路更新方案如果想要更徹底的一致性可以考慮監(jiān)聽數(shù)據(jù)庫的 Binlog在數(shù)據(jù)變更后由消費組件比如 Canal把變更事件推送到 MQ再由專門的服務更新緩存。這種方案把緩存更新邏輯和業(yè)務代碼解耦不侵入寫接口一致性保障能力也更強。但它的缺點也很明顯引入額外組件變多、開發(fā)鏈路變長、排錯成本變高不是所有業(yè)務都需要走到這一步。我的經(jīng)驗是業(yè)務體量小、并發(fā)不算高但一致性要求不苛刻用 Cache Aside 延遲雙刪業(yè)務量大一致性和穩(wěn)定性要求都高且團隊有 MQ 和中間件運維能力再考慮消息隊列或 Binlog 訂閱方案。5.4 版本號方案跨過雙刪的死角前面我提到多寫并發(fā)是延遲雙刪的死角版本號機制正好可以補齊這一塊。設計思路是在數(shù)據(jù)庫表中設計一個樂觀鎖版本號字段每次更新數(shù)據(jù)庫時 version 加 1緩存中同時存放 value 和對應的 version。讀請求讀取緩存時發(fā)現(xiàn)緩存中的 version 與數(shù)據(jù)庫最新 version 不一致就丟棄緩存中的值去數(shù)據(jù)庫加載新數(shù)據(jù)并回填。這個方案可以完全繞過“雙刪是否可以覆蓋所有讀寫時序”的問題因為讀請求本身會校驗版本一致性。但它的成本也很明顯數(shù)據(jù)庫表要加字段緩存結(jié)構(gòu)從 String 變成了攜帶版本號的復合結(jié)構(gòu)讀邏輯多一步版本比較而且數(shù)據(jù)庫每次更新都要多查或返回一次版本號。綜合消耗不小。所以我的建議是大多數(shù)場景先用 Cache Aside 延遲雙刪 緩存鎖兜底版本號方案作為極端場景的升級手段而不是默認方案。6. 常見問題與排查技巧實錄6.1 延遲多久才合理最佳答案在你的日志里不在任何文章里。先用監(jiān)控統(tǒng)計單個讀請求從發(fā)起查詢到緩存寫入完成的耗時取 P99 或者 P999 加上 200ms-500ms 安全裕度作為延遲時間。建議直接從 500ms 起步測試觀察不一致投訴率和緩存命中率的變化再逐步微調(diào)。6.2 為什么刪了緩存還是讀到舊數(shù)據(jù)排查順序分五步先看第二次刪除是否執(zhí)行成功日志和 Redis 慢命令監(jiān)控有沒有刪除命令。再看延遲線程池是否拒絕了任務是否出現(xiàn)線程池隊列滿。檢查 Redis key 是否為多個寫線程并發(fā)更新是否跨過雙刪保護邊界。檢查讀請求是否有緩存更新時間戳查詢是否走了別的旁路通道?？磾?shù)據(jù)庫連接層是否有讀寫分離延遲讀請求查的是從庫從庫同步還沒完成。6.3 雙刪和分布式鎖怎么結(jié)合如果你想盡量減少多寫并發(fā)下的不一致概率可以在更新業(yè)務上先加分布式鎖保證同一時刻只有一個寫請求在操作同一個 key。鎖粒度要能精確到“業(yè)務 key 字段”例如product:price:123。分布式鎖的作用是把多寫退化成語義上的串行寫雙刪的第二次刪除就有了明確的線性時序。不過加鎖也有性能損耗適合寫并發(fā)本身不高的場景。6.4 雙刪會犧牲多少寫性能同步雙刪的延遲會直接加到寫請求耗時上比如延遲 500ms寫接口 RT 大概率會上升幾百毫秒這對大部分后臺管理系統(tǒng)可能無所謂但對開放 API 或支付回調(diào)類接口可能不可接受。異步雙刪可以修復這個問題但一定要考慮丟任務的場景。如果丟失后沒有兜底手段那第二次刪除基本是在賭運氣。6.5 延遲雙刪是否可以完全替代緩存過期時間不可以。緩存過期時間仍然是最后一道安全兜底。無論雙刪重試做得多好總有極端情況進程被殺、網(wǎng)絡分區(qū)、Redis 掛了會導致刪除失敗。沒有 TTL 的緩存就像沒有保險的賬戶一旦出錯臟數(shù)據(jù)會被無限期讀到。所以雙刪可以縮短臟數(shù)據(jù)窗口但請保留 TTL 做最終防線。7. 我的最終建議延遲雙刪不是高深技術(shù)但它能幫我們重新理解“緩存一致性”這件事的麻煩程度。我做了這么多年后端最大體會是一致性方案沒有銀彈每個方案都有代價。延遲雙刪的代價是延遲時間難估、刪除失敗要補償消息隊列方案的代價是引入新組件和運維復雜度Binlog 訂閱的代價是鏈路過長、排障麻煩。對大多數(shù)讀多寫少、一致性窗口容忍度在 1 秒內(nèi)的業(yè)務Cache Aside 加上延遲雙刪、緩存重建鎖和 TTL 兜底已經(jīng)是一套非常成熟的組合打法。最后再給一個小技巧正式上線前拿壓測工具模擬“更新數(shù)據(jù)庫 并發(fā)讀緩存”的混合流量腳本里故意把讀請求的查詢時間拖慢比如造個慢 SQL驗證第二次刪除在極端并發(fā)下能不能兜住。這一步跑通了你的方案才算真正落地可靠。