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