緩存防御實(shí)戰(zhàn)指南)
線上業(yè)務(wù)半夜報警數(shù)據(jù)庫連接數(shù)打滿慢查詢堆積成山緩存Redis里明明還有數(shù)據(jù)上游接口卻一片超時。翻了一圈監(jiān)控發(fā)現(xiàn)罪魁禍?zhǔn)撞皇谴abug也不是流量突增而是一個本該在緩存層就被攔下來的無效請求直接穿透到了數(shù)據(jù)庫。這種事故我在不同團(tuán)隊(duì)遇到過至少三次每一次的根因都繞不開三個詞緩存穿透、緩存擊穿、緩存雪崩。這三個問題聽起來像兄弟實(shí)際上成因、表現(xiàn)、殺傷力完全不同對應(yīng)的防御方案也各有講究。這篇內(nèi)容我打算把這三個“高并發(fā)緩存殺手”一次性講透從原理層面拆解它們?yōu)槭裁磿寯?shù)據(jù)庫崩潰再到布隆過濾器、互斥鎖、多級緩存這些主流防御手段的落地細(xì)節(jié)。文章會貼大量實(shí)操代碼、參數(shù)配置和我在生產(chǎn)環(huán)境里實(shí)測過的數(shù)據(jù)適合正在維護(hù)高并發(fā)服務(wù)的后端開發(fā)、架構(gòu)師以及準(zhǔn)備系統(tǒng)學(xué)習(xí)緩存知識的技術(shù)人?？赐曛竽阒辽倌芨闱宄患庐?dāng)緩存失效的那一瞬間你的系統(tǒng)到底在經(jīng)歷什么以及怎么把它扛住。1. 三種緩存失效場景別再把它們混為一談很多文章把穿透、擊穿、雪崩并列來講但實(shí)際工作中我發(fā)現(xiàn)很多人對這三個概念停留在“都會導(dǎo)致數(shù)據(jù)庫壓力暴增”的模糊印象。其實(shí)它們的觸發(fā)條件、影響范圍、修復(fù)手段差別非常大搞混了會直接導(dǎo)致方案選型錯誤。我先用最直白的方式把它們區(qū)分開。1.1 緩存穿透查詢了一個根本不存在的數(shù)據(jù)穿透的本質(zhì)是請求的key在緩存中不存在在數(shù)據(jù)庫中也不存在于是每次請求都直接打到數(shù)據(jù)庫。攻擊者如果構(gòu)造一批隨機(jī)不存在的ID比如負(fù)數(shù)ID、超長字符串、隨機(jī)UUID就能讓數(shù)據(jù)庫承受大量無意義的查詢。舉個例子。一個電商訂單查詢接口訂單號是19位數(shù)字。正常情況下用戶查的都是真實(shí)訂單第一次查詢沒命中緩存回源數(shù)據(jù)庫然后回填緩存。但如果有惡意請求連續(xù)傳入12938192831928391283這種并不存在的訂單號緩存永遠(yuǎn)不可能命中數(shù)據(jù)庫每次都要去做一次全表掃描級別的查詢連接池很快就會被耗盡。最陰險的地方在于這種流量很難通過常規(guī)的限流手段識別因?yàn)樗鼈兊膮?shù)看起來完全合法只是在業(yè)務(wù)語義上不存在。而且穿透請求往往帶有隨機(jī)性緩存中不可能被提前寫入這些key所以緩存層約等于透明。1.2 緩存擊穿熱點(diǎn)Key在過期瞬間被高并發(fā)打穿擊穿針對的是某一個熱點(diǎn)Key。比如一個秒殺商品的詳情頁平時QPS可能只有幾百活動開始后瞬間飆升到幾萬。這個商品信息的緩存設(shè)置了30分鐘過期緩存服務(wù)在過期時間到達(dá)的那一刻如果正好有一大批請求同時來查這個Key從Redis中取不到數(shù)據(jù)它們會一起回源數(shù)據(jù)庫。這里的關(guān)鍵詞是“同時”。如果只有一兩個請求回源數(shù)據(jù)庫毫無壓力但如果同一時刻有幾千個請求同時回源數(shù)據(jù)庫瞬間就被打垮。擊穿和穿透的最大區(qū)別是擊穿的數(shù)據(jù)在數(shù)據(jù)庫中是真實(shí)存在的只是緩存恰好過期穿透的數(shù)據(jù)在數(shù)據(jù)庫中壓根不存在永遠(yuǎn)無法回填緩存。對業(yè)務(wù)的影響也完全不同擊穿恢復(fù)后緩存會被重新回填系統(tǒng)能自動恢復(fù)穿透則會持續(xù)打數(shù)據(jù)庫直到流量停止或采取了額外防護(hù)。1.3 緩存雪崩大量Key同時過期導(dǎo)致緩存層整體失效雪崩的覆蓋面比擊穿大得多。如果一批緩存Key設(shè)置的過期時間相同比如都是整點(diǎn)過期、都是30分鐘過期到了某個時間點(diǎn)這大批Key會一起失效。此時請求全部回源數(shù)據(jù)庫數(shù)據(jù)庫壓力瞬間達(dá)到峰值很容易觸發(fā)連接池耗盡、慢查詢堆積、主從延遲等一系列連鎖反應(yīng)。我見過一個典型事故運(yùn)營人員把一批活動頁面的緩存過期時間統(tǒng)一設(shè)置為600秒結(jié)果每天上午10點(diǎn)整這批頁面同時刷新數(shù)據(jù)庫在10點(diǎn)整那一分鐘內(nèi)的QPS比平時翻了20倍直接宕機(jī)。更麻煩的是Redis中大量Key失效后如果緩存服務(wù)本身也扛不住回源請求比如Redis線程被阻塞故障會從數(shù)據(jù)庫向上蔓延形成級聯(lián)效應(yīng)。還有一種雪崩場景不是Key過期導(dǎo)致的而是Redis實(shí)例宕機(jī)。Redis掛了之后所有請求直接繞過緩存打到數(shù)據(jù)庫這種物理級別的雪崩往往比Key過期更致命因?yàn)榫彺鎸用嬉呀?jīng)完全沒有保護(hù)能力。1.4 三兄弟對比一張表看懂差異維度緩存穿透緩存擊穿緩存雪崩觸發(fā)場景查詢不存在的Key單個熱點(diǎn)Key過期大量Key同時過期 / Redis宕機(jī)數(shù)據(jù)真實(shí)性數(shù)據(jù)庫不存在數(shù)據(jù)庫存在數(shù)據(jù)庫存在影響范圍單個無效請求持續(xù)不斷單個Key高并發(fā)瞬間多個Key全局性壓力恢復(fù)方式無需回填需要攔截回填緩存自動恢復(fù)回填大量緩存耗時較長核心防御布隆過濾器、空值緩存互斥鎖、邏輯過期過期時間隨機(jī)、多級緩存、高可用分清這三種場景之后下面我逐個講對應(yīng)的防御方案每一步都會給出可以直接抄作業(yè)的實(shí)現(xiàn)。2. 布隆過濾器攔截穿透請求的第一道閘門布隆過濾器的核心價值在于用極低的內(nèi)存成本快速判斷一個Key“一定不存在”。它允許誤判存在但不允許誤判不存在。也就是說如果布隆過濾器說“這個Key不存在”那它一定不存在可以安心攔截如果它說“可能存在”則需要放行到后續(xù)邏輯去驗(yàn)證。2.1 布隆過濾器的原理和數(shù)學(xué)直覺布隆過濾器的底層是一個位數(shù)組bit數(shù)組 一組哈希函數(shù)。插入一個Key時用k個哈希函數(shù)分別計算得到k個位置把這些位置上的bit全部置為1查詢一個Key時同樣計算k個位置如果所有位置都是1則認(rèn)為“可能存在”只要有一個位置是0就認(rèn)為“一定不存在”。為什么說“可能存在”因?yàn)楣Ｅ鲎病２煌琄ey可能映射到相同的位置導(dǎo)致某個Key雖然沒有插入過但它的所有哈希位置都已經(jīng)被其他Key置為1這就產(chǎn)生了誤判。誤判率可以估算經(jīng)典公式是誤判率 p ≈ (1 - e^(-kn/m))^k其中n是預(yù)計插入的元素數(shù)量m是位數(shù)組長度k是哈希函數(shù)個數(shù)。實(shí)際操作中可以先預(yù)估n然后根據(jù)可接受的誤判率p反推m和k。常用的簡化公式是m -n * ln(p) / (ln2)^2 k m/n * ln2舉個例子。假設(shè)預(yù)計插入100萬個訂單號希望誤判率控制在1%代入公式m約等于958萬位換算成字節(jié)約1.2MBk約等于7。也就是說用1.2MB內(nèi)存和一億分之一的誤判概率就能擋住幾乎所有不存在的Key查詢。這個性價比非常高。2.2 布隆過濾器在生產(chǎn)環(huán)境中的三種落地姿勢第一Guava的BloomFilter。適合單機(jī)應(yīng)用數(shù)據(jù)在本地內(nèi)存中加載后只能單機(jī)判斷。對于部署在多個實(shí)例上的服務(wù)每個實(shí)例都需要各自構(gòu)建一份適合Key集合相對固定、實(shí)例數(shù)不多、數(shù)據(jù)量在百萬級的場景。BloomFilterString filter BloomFilter.create( Funnels.stringFunnel(StandardCharsets.UTF_8), 1_000_000, // 預(yù)計元素數(shù) 0.01); // 期望誤判率 filter.put(order_123456); boolean mightContain filter.mightContain(order_987654);第二Redis的布隆過濾器插件。Redis 4.0之后可以通過模塊方式安裝bf命令常見的是RedisBloom模塊。這種方式的好處是過濾器數(shù)據(jù)集中在Redis中所有應(yīng)用實(shí)例共享同一個判斷結(jié)果不必每個實(shí)例各自構(gòu)建。缺點(diǎn)是Redis需要額外加載模塊有一定的運(yùn)維成本。BF.RESERVE order_filter 0.01 1000000 BF.ADD order_filter order_123456 BF.EXISTS order_filter order_987654第三基于Redis字符串位圖手動實(shí)現(xiàn)。用SETBIT和GETBIT命令來模擬位數(shù)組操作代碼可控性強(qiáng)不依賴額外模塊適合已有Redis集群不想引入新組件的情況。不過哈希函數(shù)需要自己在代碼里實(shí)現(xiàn)處理起來稍微繁瑣一些。2.3 布隆過濾器誤判的后果和處理方法誤判意味著某些不存在的Key會被放行到數(shù)據(jù)庫。雖然誤判率可以控制在1%甚至更低但1%的無效回源請求在千萬級QPS下依然很可觀。所以要組合使用布隆過濾器做第一層攔截攔截掉99%的穿透流量剩下1%的漏網(wǎng)之魚再用空值緩存方案兜底——把查詢結(jié)果為null的Key也緩存起來設(shè)置一個較短的過期時間比如60秒。這樣即使布隆過濾器誤判放行第二次相同請求也會被空值緩存擋住。我在實(shí)際項(xiàng)目中推薦的組合邏輯是請求進(jìn)來 - 布隆過濾器判斷不存在 - 直接返回空結(jié)果 請求進(jìn)來 - 布隆過濾器判斷可能存在 - 查Redis緩存 - 命中直接返回 請求進(jìn)來 - 布隆過濾器判斷可能存在 - 查Redis緩存未命中 - 查數(shù)據(jù)庫 - 回填緩存含空值緩存注意布隆過濾器無法刪除元素。如果想刪除舊數(shù)據(jù)只能用“定期重建過濾器”的方式或者選擇支持刪除的變體比如布谷鳥過濾器但這個變體的實(shí)現(xiàn)復(fù)雜度會明顯上升。3. 互斥鎖與邏輯過期擊穿防御的兩條實(shí)戰(zhàn)路線擊穿的核心矛盾是熱點(diǎn)Key過期后一瞬間有大量并發(fā)請求同時回源。要解決這個問題思路很簡單——讓這些請求不要同時回源而是只放一個請求去數(shù)據(jù)庫重建緩存其余請求要么等要么拿舊值。3.1 互斥鎖方案的實(shí)現(xiàn)細(xì)節(jié)互斥鎖的思路是當(dāng)緩存未命中時不是立刻查數(shù)據(jù)庫而是先嘗試獲取一把分布式鎖。拿到鎖的請求去查數(shù)據(jù)庫并回填緩存其他請求在鎖上等待然后重新讀取緩存。這里的關(guān)鍵問題是用哪種分布式鎖等待多久鎖何時釋放我推薦直接用Redis的SET NX PX命令實(shí)現(xiàn)避免引入額外的ZooKeeper或Etcd依賴畢竟Redis已經(jīng)在鏈路里了。// 嘗試獲取鎖設(shè)置5秒超時 String token UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lock:hot_key, token, Duration.ofSeconds(5)); if (Boolean.TRUE.equals(locked)) { try { // 二次檢查緩存防止在等鎖期間緩存已經(jīng)被其他線程重建 Object cached redisTemplate.opsForValue().get(key); if (cached ! null) { return cached; } // 查數(shù)據(jù)庫 Object data queryFromDatabase(key); redisTemplate.opsForValue().set(key, data, Duration.ofSeconds(600)); return data; } finally { // 釋放鎖時需要校驗(yàn)持有者身份防止誤刪其他線程的鎖 String lockValue redisTemplate.opsForValue().get(lock:hot_key); if (token.equals(lockValue)) { redisTemplate.delete(lock:hot_key); } } } else { // 沒拿到鎖休眠一小段時間后重試 Thread.sleep(50); return getFromCacheOrDb(key); // 遞歸重試注意控制重試次數(shù) }這段代碼有幾個細(xì)節(jié)值得展開。關(guān)于鎖的持有者校驗(yàn)釋放鎖時如果直接delete可能把其他線程剛獲取的新鎖誤刪。比如線程A的鎖5秒超時自動釋放線程B獲取了新鎖此時線程A的finally塊執(zhí)行delete就會把B的鎖刪掉導(dǎo)致B的互斥失效。所以釋放前必須比對value值我這里用UUID做標(biāo)識只有持有者自己才能刪除。關(guān)于等待和重試沒拿到鎖就短睡眠然后遞歸重試但這個遞歸需要加次數(shù)限制。我見過一個線上問題熱點(diǎn)Key的數(shù)據(jù)庫查詢特別慢超過鎖的5秒超時第一個線程的鎖已經(jīng)自動失效了第二個線程拿到鎖又開始查庫結(jié)果多個線程實(shí)際上都在查庫互斥完全失效。所以鎖超時時間必須大于“建緩存”的耗時通常建議壓測后確定一般取數(shù)據(jù)庫查詢耗時的3-5倍。關(guān)于JVM內(nèi)鎖的補(bǔ)充如果所有請求都落在同一個Java進(jìn)程內(nèi)用JDK內(nèi)置的synchronized或ReentrantLock做本地鎖就夠了性能遠(yuǎn)高于分布式鎖。只有當(dāng)服務(wù)是集群部署時才需要跨進(jìn)程的分布式鎖。我常用的優(yōu)化方案是“本地鎖分布式鎖”兩級結(jié)合先獲取本地鎖同一個實(shí)例內(nèi)的并發(fā)先被本地鎖擋掉只有不同實(shí)例之間才需要競爭分布式鎖。這種方式能大幅減少Redis鎖請求的壓力。3.2 邏輯過期方案用舊數(shù)據(jù)扛過真空期互斥鎖的痛點(diǎn)是如果熱點(diǎn)Key過期瞬間有大量請求在等待響應(yīng)時間會變長重試也會占用線程資源。邏輯過期方案則完全不同——它不存在“緩存過期”的概念。具體做法是緩存數(shù)據(jù)中額外存儲一個邏輯過期時間字段但Redis中的Key本身不過期或者設(shè)置一個很長的物理過期時間。請求讀取到數(shù)據(jù)后先判斷邏輯過期時間是否已到。如果沒過期直接返回如果已過期則嘗試獲取互斥鎖獲取成功后開啟一個異步線程去數(shù)據(jù)庫更新緩存當(dāng)前請求則直接返回“過期的舊數(shù)據(jù)”。public Object getProductInfo(String key) { // 從緩存讀取Redis中的Key永不過期 String json redisTemplate.opsForValue().get(key); if (json null) { return null; // 理論上這種情況非常少Key被手動清理了 } CacheEntry entry JSON.parseObject(json, CacheEntry.class); if (entry.getExpireTime() System.currentTimeMillis()) { return entry.getData(); // 邏輯時間未過期直接返回 } // 邏輯過期嘗試獲取鎖異步刷新 if (tryGetLock(key)) { try { // 異步更新緩存 executorService.submit(() - { Object data queryFromDatabase(key); String newJson JSON.toJSONString(new CacheEntry(data, System.currentTimeMillis() 600_000)); redisTemplate.opsForValue().set(key, newJson); }); } finally { releaseLock(key); } } // 未拿到鎖的請求直接返回舊數(shù)據(jù) return entry.getData(); }這個方案的核心優(yōu)勢是請求永遠(yuǎn)都不會因?yàn)榫彺孢^期而等待響應(yīng)時間穩(wěn)定。核心缺點(diǎn)是在緩存異步更新的窗口期內(nèi)用戶看到的是舊數(shù)據(jù)。對于實(shí)時性要求不高的場景比如商品詳情、文章內(nèi)容、配置信息這個缺點(diǎn)完全可以接受。但如果數(shù)據(jù)是余額、庫存這種強(qiáng)一致要求的數(shù)據(jù)就不能用邏輯過期。這里有一個生產(chǎn)環(huán)境常見的坑異步線程池如果處理不過來緩存永遠(yuǎn)不更新舊數(shù)據(jù)會一直返回。所以要給這個線程池加上合理的隊(duì)列大小、拒絕策略和監(jiān)控報警。我一般用獨(dú)立線程池核心線程數(shù)和最大線程數(shù)根據(jù)數(shù)據(jù)庫能承受的并發(fā)來定同時監(jiān)控隊(duì)列深度超過閾值就報警。4. 雪崩防御多級緩存與過期時間的藝術(shù)雪崩的殺傷力在于覆蓋面大動輒幾十上百個Key同時失效。防御思路也分兩條一是讓失效時間分散二是讓數(shù)據(jù)庫上面不止緩存一道防線。4.1 過期時間的隨機(jī)化與業(yè)務(wù)錯峰最基礎(chǔ)的方案是把固定的過期時間改成“基礎(chǔ)過期時間隨機(jī)偏移量”。比如原來統(tǒng)一3600秒現(xiàn)在改成“3600 隨機(jī)數(shù)60~600秒”。這個策略在代碼里改動最小卻能顯著降低同時失效的概率。基礎(chǔ)時間 隨機(jī)偏移 實(shí)際過期時間 3600 random(60, 600) 3660~4200秒要注意的一點(diǎn)是不要所有Key都用一個隨機(jī)算法生成完全隨機(jī)的過期時間那樣會導(dǎo)致緩存命中率下降。更好的做法是“按業(yè)務(wù)分組打散”。比如活動頁面的Key集中在300~600秒隨機(jī)商品詳情的Key集中在3600~7200秒隨機(jī)這樣同類Key的過期時間大致在一個接近的區(qū)間但具體時間點(diǎn)錯開既保持了緩存效果又避免了集中失效。另一個工程上的細(xì)節(jié)很多團(tuán)隊(duì)用同一個RedisTemplate的set(key, value, time)方法設(shè)置緩存如果key的命名規(guī)則里包含業(yè)務(wù)前綴可以通過前綴來配置不同的隨機(jī)范圍。我習(xí)慣在緩存工具類中維護(hù)一個過期時間策略表用Map維護(hù)前綴和隨機(jī)范圍新增緩存場景時只需要加一行配置而不需要到處改業(yè)務(wù)代碼。4.2 多級緩存把壓力分散到更靠近用戶的地方當(dāng)Redis整實(shí)例宕機(jī)時隨機(jī)化過期時間完全失效。這時真正能扛住的是多級緩存架構(gòu)。常見的分級是本地緩存Caffeine - Redis緩存 - 數(shù)據(jù)庫。本地緩存放在應(yīng)用進(jìn)程內(nèi)讀寫納秒級不依賴網(wǎng)絡(luò)。即使Redis掛了只要本地緩存還有數(shù)據(jù)請求就不會打到數(shù)據(jù)庫。這里最常用的組件是Caffeine它支持基于時間的過期策略和基于大小的淘汰策略。CacheString, Object localCache Caffeine.newBuilder() .maximumSize(10_000) // 最多緩存1萬個Key .expireAfterWrite(Duration.ofSeconds(30)) // 寫入30秒后過期 .build();讀流程變成讀取本地緩存 - 未命中則讀取Redis - 未命中則查數(shù)據(jù)庫 - 回填兩級緩存這里強(qiáng)調(diào)一個關(guān)鍵點(diǎn)本地緩存的過期時間必須比Redis短。否則本地緩存長期持有舊數(shù)據(jù)Redis中的數(shù)據(jù)更新后本地緩存感知不到就會出現(xiàn)數(shù)據(jù)不一致。常見的設(shè)置為本地緩存30秒Redis緩存10-15分鐘。這樣Redis更新后最多30秒內(nèi)本地緩存會過期重新從Redis拉取新數(shù)據(jù)。多級緩存最大的槽點(diǎn)是數(shù)據(jù)一致性。如果后臺更新了數(shù)據(jù)庫需要主動失效Redis中的舊緩存但本地緩存分布在每個應(yīng)用實(shí)例中無法統(tǒng)一失效。我的實(shí)踐經(jīng)驗(yàn)是對一致性要求不高的讀取場景接受本地緩存30秒的短時不一致對一致性要求較高的場景不要加本地緩存直接走Redis。4.3 Redis高可用的兜底還有一個層面需要重視Redis本身的可用性。Redis主從切換、哨兵、集群模式都是基礎(chǔ)設(shè)施層面的雪崩防御。但要注意的是即便Redis是高可用的主從切換的那幾秒內(nèi)緩存寫入依然可能失敗。所以在業(yè)務(wù)代碼中寫緩存必須捕獲異常并降級不能因?yàn)镽edis報錯而影響主流程。try { redisTemplate.opsForValue().set(key, value, timeout); } catch (Exception e) { // Redis異常時降級本次不寫緩存下次請求繼續(xù)嘗試 log.warn(write redis failed, e); }同理讀緩存也要做降級。如果Redis讀超時不要拋異常讓請求失敗而是直接返回null并進(jìn)入數(shù)據(jù)庫查詢流程。雖然這會加重數(shù)據(jù)庫壓力但至少業(yè)務(wù)是可用的配合熔斷機(jī)制可以控制住影響范圍。5. 一套完整的防御體系高并發(fā)讀接口的落地框架前面分別講了穿透、擊穿、雪崩的防御手段但真實(shí)的生產(chǎn)環(huán)境要的是把這些手段組合成一個統(tǒng)一的讀接口框架而不是在每一個業(yè)務(wù)代碼里東拼西湊。我構(gòu)建過一套比較通用的“四級防御”讀接口在這里給出完整的設(shè)計。5.1 四級防御鏈路拆解整個讀請求的流程可以分為四層第一層本地緩存。Caffeine承載過期時間30秒。這一層的目的是扛住極端QPS下對Redis的壓力。如果本地緩存命中整體響應(yīng)時間在毫秒級。第二層布隆過濾器。判斷Key是否可能存在。如果不存在直接返回空結(jié)果或緩存中的空標(biāo)記杜絕穿透流量進(jìn)入數(shù)據(jù)庫。布隆過濾器可以放在RedisRedisBloom模塊中也可以放在本地Guava根據(jù)數(shù)據(jù)量權(quán)衡。第三層Redis緩存。承載主要的緩存命中流量過期時間根據(jù)業(yè)務(wù)配置采用基礎(chǔ)時間隨機(jī)偏移。這一層是系統(tǒng)的主力緩存層。第四層數(shù)據(jù)庫。只有前面三層全部未命中才會到達(dá)這一層。到達(dá)這一層時還要用互斥鎖控制并發(fā)回源的數(shù)量保證同時只有少數(shù)請求在查庫。5.2 統(tǒng)一的讀接口模板代碼下面是我常用的一個泛型化模板的骨架業(yè)務(wù)方只需要傳入Key生成函數(shù)和數(shù)據(jù)庫查詢函數(shù)public T T queryWithDefense(String key, FunctionString, T dbQuery, ClassT clazz) { // 本地緩存1Caffeine Object local localCache.getIfPresent(key); if (local ! null) { return (T) local; } // 防線2布隆過濾器不存在直接返回 if (!bloomFilter.mightContain(key)) { return null; } // 防線3Redis緩存 String json redisTemplate.opsForValue().get(key); if (json ! null) { T data JSON.parseObject(json, clazz); localCache.put(key, data); // 回填本地緩存 return data; } // 防線4互斥鎖控制回源 T data loadFromDbWithLock(key, dbQuery, clazz); if (data ! null) { localCache.put(key, data); } return data; }要注意的是這個模板把布隆過濾器的判斷放在Redis緩存之前。這么做的原因是布隆過濾器的查詢時間比較快而且如果它判斷Key不存在就沒有必要再去Redis執(zhí)行一次G一邊GET。另一個細(xì)節(jié)如果業(yè)務(wù)允許一定程度的延遲這里的“防線2”可以在本地緩存中實(shí)現(xiàn)但如果布隆過濾器數(shù)據(jù)量較大本地內(nèi)存撐不住就必須放在Redis中。5.3 實(shí)測效果與調(diào)優(yōu)參數(shù)參考我把這套框架用在一個商品詳情接口上壓測結(jié)果供大家參考接口原生QPS約800數(shù)據(jù)庫單機(jī)可承受約2000 QPS的查詢。加四級防御后Jmeter壓測線程數(shù)從100調(diào)到1000數(shù)據(jù)庫實(shí)際接收的查詢QPS穩(wěn)定在30左右接口P99響應(yīng)時間從40ms降到了12ms。主要參數(shù)配置是這樣的參數(shù)值說明本地緩存過期時間30秒必須小于Redis緩存過期時間本地緩存最大條目10000防止內(nèi)存溢出需要根據(jù)Heap大小調(diào)整Redis緩存過期時間600秒隨機(jī)120秒兼顧命中率和防雪崩布隆過濾器預(yù)計元素量實(shí)際數(shù)據(jù)量×1.1留出10%余量布隆過濾器誤判率0.01取值越低內(nèi)存越大鎖超時時間5秒大于數(shù)據(jù)庫慢查詢耗時異步刷新線程池核心4最大8隊(duì)列1000根據(jù)數(shù)據(jù)庫能力配置這個配置不是固定不變的僅供參考。核心原則是數(shù)據(jù)庫回源量必須壓到數(shù)據(jù)庫能承受的范圍以內(nèi)同時保證緩存命中率在95%以上。6. 常見問題與排查技巧實(shí)錄在實(shí)際維護(hù)這套體系的過程中我踩過不少坑也總結(jié)了一些排查路徑。單獨(dú)拎出來說一遍可能比上面那些代碼更有價值。6.1 布隆過濾器誤判偏高怎么辦誤判率升高先別急著調(diào)大位數(shù)組。排查一下是不是數(shù)據(jù)量增長超出預(yù)期導(dǎo)致初始化的n值過小。比如你初始化的預(yù)計元素量是100萬實(shí)際寫進(jìn)了500萬誤判率會急劇升高。解決辦法是監(jiān)控過濾器中的BF.INFORedisBloom或者布隆過濾器當(dāng)前元素數(shù)的估算值超過預(yù)計量的80%就觸發(fā)自動重建或者提前把預(yù)計量設(shè)大一點(diǎn)。還有一個容易忽略的問題業(yè)務(wù)代碼中對Key的序列化方式不統(tǒng)一。有的地方用String有的地方用DigestUtils.md5DigestAsHex做了哈希如果Key的格式不統(tǒng)一布隆過濾器中的數(shù)據(jù)和查詢的數(shù)據(jù)無法對應(yīng)會產(chǎn)生大量“假誤判”。排查時可以先打日志確認(rèn)同一個Key在寫入和查詢時經(jīng)過的字符串是否完全一致。6.2 互斥鎖失效緩存被重復(fù)重建鎖失效最典型的場景是持鎖線程執(zhí)行時間超過了鎖的自動過期時間。鎖被Redis自動刪除后其他線程又拿到新鎖造成多個線程同時查庫。排查時看日志里“acquire lock”和“release lock”的間隔如果經(jīng)常接近鎖超時時間說明建緩存過程太慢需要優(yōu)化數(shù)據(jù)庫查詢或者把鎖的超時時間拉長。還有一個更隱蔽的問題鎖的key設(shè)置了過期時間但釋放鎖時用delete命令如果恰好在這個時刻鎖已經(jīng)過期刪除操作就會把別人剛創(chuàng)建的新鎖刪掉。前面代碼里面已經(jīng)提到解決方案就是用UUID作為鎖的value并校驗(yàn)后再刪。這個細(xì)節(jié)能擋住很多人都會踩的坑。6.3 多級緩存數(shù)據(jù)不一致如何緩解多級緩存一定會面臨不一致的問題。Redis更新了本地緩存可能還是舊數(shù)據(jù)數(shù)據(jù)庫更新了Redis緩存也還是舊數(shù)據(jù)。我的建議是不要追求強(qiáng)一致而是把一個可接受的不一致時間明確寫進(jìn)文檔。對于主動更新的場景可以在更新數(shù)據(jù)庫后先刪Redis緩存再通過延遲雙刪1秒后再次刪除來清理可能被讀請求重新寫入的舊緩存。本地緩存這邊如果框架支持消息通知可以通過Redis的Pub/Sub廣播一個“清本地緩存”的消息如果沒條件就接受它最多30秒的過期時間。重要提示多級緩存的一致性考驗(yàn)的不是技術(shù)而是業(yè)務(wù)容忍度。設(shè)計架構(gòu)前先和業(yè)務(wù)方確認(rèn)數(shù)據(jù)更新后最多可以接受多少秒的延遲把這個數(shù)字寫清楚比你用再高級的組件都重要。6.4 緩存回填風(fēng)暴的預(yù)防當(dāng)大量緩存同時失效時回填過程本身也會造成數(shù)據(jù)庫壓力。除了隨機(jī)過期時間以外還有個技巧是“回填節(jié)流”——不是所有請求都去數(shù)據(jù)庫回填而是只讓一部分請求去查詢其他請求直接返回默認(rèn)值或空數(shù)據(jù)。比如用互斥鎖保證同一時刻只有一個請求回填或者用一個“回填信號量”控制全局的最大回填并發(fā)數(shù)。我在高并發(fā)場景下還用過一種“漸進(jìn)式回填”緩存失效時返回的舊數(shù)據(jù)里帶一個refresh_after字段表示“這個數(shù)據(jù)最多再服務(wù)多久”。到達(dá)這個時間后只允許一個異步任務(wù)去刷新而同步請求永遠(yuǎn)拿舊數(shù)據(jù)。這是邏輯過期方案的變種非常適用于數(shù)據(jù)更新不頻繁但讀取量極大的場景。7. 這些方案的邊界和取舍布隆過濾器、互斥鎖、多級緩存這些方案都不是銀彈它們有各自的邊界。我在實(shí)際項(xiàng)目中反復(fù)調(diào)整過很多次逐漸摸索出一些取舍的經(jīng)驗(yàn)。布隆過濾器最大的邊界是它只能用于“判斷存在性”不適合作為唯一的穿透防御。如果業(yè)務(wù)中合法請求都是“近期創(chuàng)建的數(shù)據(jù)”那么布隆過濾器很快就會被塞滿重建成本很高。這種情況下空值緩存也許更直接。兩種方案可以組合空值緩存放Redis布隆過濾器放本地前者兜底后者攔截絕大多數(shù)惡意流量。互斥鎖的邊界在于它本質(zhì)上是在“用性能換一致性”——請求需要等待必然增加延遲。如果熱點(diǎn)Key的過期頻率很高比如每分鐘都過期那么鎖競爭本身就會成為新的瓶頸。這時候邏輯過期方案更合適因?yàn)樗鼛缀鯖]有鎖等待。多級緩存的邊界在于“數(shù)據(jù)一致性”和“內(nèi)存成本”。本地緩存的引入意味著每個應(yīng)用實(shí)例要額外占用內(nèi)存如果緩存條目太大會導(dǎo)致JVM GC壓力上升。選擇哪些數(shù)據(jù)進(jìn)本地緩存、哪些只走Redis需要按數(shù)據(jù)熱度來分。熱度高的、讀取量大的、一致性要求低的數(shù)據(jù)才適合放本地。我個人的原則是先解決主要矛盾。如果問題是穿透流量大優(yōu)先上布隆過濾器如果問題是熱點(diǎn)數(shù)據(jù)偶爾過期導(dǎo)致抖動優(yōu)先上互斥鎖如果問題是周期性雪崩優(yōu)先隨機(jī)化過期時間。不要一上來就上一個全量的“緩存防御全家桶”復(fù)雜度會翻倍排查問題的難度也會翻倍。8. 一次真實(shí)事故的復(fù)盤從報警到修復(fù)的完整思路最后分享一次我親身經(jīng)歷的事故把前面這些理論串起來看效果會更好。某次大促預(yù)熱期凌晨兩點(diǎn)監(jiān)控突然報警數(shù)據(jù)庫CPU打滿慢查詢暴漲。查看Redis的hit ratio從平時的98%掉到了76%。第一反應(yīng)是查RedisKey的過期情況發(fā)現(xiàn)大量活動相關(guān)的Key同時過期——運(yùn)營同學(xué)在后臺定時任務(wù)里批量刷新活動數(shù)據(jù)刷新代碼統(tǒng)一設(shè)置的過期時間是300秒而定時任務(wù)每5分鐘執(zhí)行一次相當(dāng)于每300秒就有幾百個Key同時被重建。解決思路分了三步第一步止血。臨時把定時任務(wù)的刷新邏輯改掉刷新完成后不刪舊緩存而是先更新數(shù)據(jù)庫再通過異步任務(wù)在后臺批量重寫緩存讓緩存過期時間錯開。這一步花了5分鐘數(shù)據(jù)庫壓力立即回落。第二步治理。把活動緩存代碼統(tǒng)一改成隨機(jī)過期時間并且加了一個開關(guān)如果某個批次Key的數(shù)量超過閾值就隨機(jī)挑選其中一半先刷新剩下的延遲30秒再刷新避免瞬時并發(fā)回填。第三步預(yù)防穿透。大促當(dāng)天存在大量用戶反復(fù)刷新不存在的活動頁面布隆過濾器提前添加了所有活動ID的集合無效請求在過濾器就直接被攔掉。事故復(fù)盤后我意識到一個核心問題很多緩存故障不是技術(shù)方案不行而是業(yè)務(wù)側(cè)的定時任務(wù)、批量操作沒有考慮緩存失效的“共振效應(yīng)”。技術(shù)防御是必要的但更重要的是在業(yè)務(wù)流程中加入緩存意識——比如批量更新數(shù)據(jù)的任務(wù)一定要把“集中過期”作為一項(xiàng)風(fēng)險來評估。這套防御體系我的建議是你不用全上根據(jù)自己的業(yè)務(wù)體量從布隆過濾器或互斥鎖選一個開始逐步疊加。先把最痛的那一個問題解決了再考慮引入更多組件。緩存這層看上去簡單但真正要扛住高并發(fā)那些“緩存失效瞬間”的處理才見功底。 緩存穿透、擊穿、雪崩一次講透：高并發(fā)緩存防御實(shí)戰(zhàn)指南
線上業(yè)務(wù)半夜報警數(shù)據(jù)庫連接數(shù)打滿慢查詢堆積成山緩存Redis里明明還有數(shù)據(jù)上游接口卻一片超時。翻了一圈監(jiān)控發(fā)現(xiàn)罪魁禍?zhǔn)撞皇谴abug也不是流量突增而是一個本該在緩存層就被攔下來的無效請求直接穿透到了數(shù)據(jù)庫。這種事故我在不同團(tuán)隊(duì)遇到過至少三次每一次的根因都繞不開三個詞緩存穿透、緩存擊穿、緩存雪崩。這三個問題聽起來像兄弟實(shí)際上成因、表現(xiàn)、殺傷力完全不同對應(yīng)的防御方案也各有講究。這篇內(nèi)容我打算把這三個“高并發(fā)緩存殺手”一次性講透從原理層面拆解它們?yōu)槭裁磿寯?shù)據(jù)庫崩潰再到布隆過濾器、互斥鎖、多級緩存這些主流防御手段的落地細(xì)節(jié)。文章會貼大量實(shí)操代碼、參數(shù)配置和我在生產(chǎn)環(huán)境里實(shí)測過的數(shù)據(jù)適合正在維護(hù)高并發(fā)服務(wù)的后端開發(fā)、架構(gòu)師以及準(zhǔn)備系統(tǒng)學(xué)習(xí)緩存知識的技術(shù)人?？赐曛竽阒辽倌芨闱宄患庐?dāng)緩存失效的那一瞬間你的系統(tǒng)到底在經(jīng)歷什么以及怎么把它扛住。1. 三種緩存失效場景別再把它們混為一談很多文章把穿透、擊穿、雪崩并列來講但實(shí)際工作中我發(fā)現(xiàn)很多人對這三個概念停留在“都會導(dǎo)致數(shù)據(jù)庫壓力暴增”的模糊印象。其實(shí)它們的觸發(fā)條件、影響范圍、修復(fù)手段差別非常大搞混了會直接導(dǎo)致方案選型錯誤。我先用最直白的方式把它們區(qū)分開。1.1 緩存穿透查詢了一個根本不存在的數(shù)據(jù)穿透的本質(zhì)是請求的key在緩存中不存在在數(shù)據(jù)庫中也不存在于是每次請求都直接打到數(shù)據(jù)庫。攻擊者如果構(gòu)造一批隨機(jī)不存在的ID比如負(fù)數(shù)ID、超長字符串、隨機(jī)UUID就能讓數(shù)據(jù)庫承受大量無意義的查詢。舉個例子。一個電商訂單查詢接口訂單號是19位數(shù)字。正常情況下用戶查的都是真實(shí)訂單第一次查詢沒命中緩存回源數(shù)據(jù)庫然后回填緩存。但如果有惡意請求連續(xù)傳入12938192831928391283這種并不存在的訂單號緩存永遠(yuǎn)不可能命中數(shù)據(jù)庫每次都要去做一次全表掃描級別的查詢連接池很快就會被耗盡。最陰險的地方在于這種流量很難通過常規(guī)的限流手段識別因?yàn)樗鼈兊膮?shù)看起來完全合法只是在業(yè)務(wù)語義上不存在。而且穿透請求往往帶有隨機(jī)性緩存中不可能被提前寫入這些key所以緩存層約等于透明。1.2 緩存擊穿熱點(diǎn)Key在過期瞬間被高并發(fā)打穿擊穿針對的是某一個熱點(diǎn)Key。比如一個秒殺商品的詳情頁平時QPS可能只有幾百活動開始后瞬間飆升到幾萬。這個商品信息的緩存設(shè)置了30分鐘過期緩存服務(wù)在過期時間到達(dá)的那一刻如果正好有一大批請求同時來查這個Key從Redis中取不到數(shù)據(jù)它們會一起回源數(shù)據(jù)庫。這里的關(guān)鍵詞是“同時”。如果只有一兩個請求回源數(shù)據(jù)庫毫無壓力但如果同一時刻有幾千個請求同時回源數(shù)據(jù)庫瞬間就被打垮。擊穿和穿透的最大區(qū)別是擊穿的數(shù)據(jù)在數(shù)據(jù)庫中是真實(shí)存在的只是緩存恰好過期穿透的數(shù)據(jù)在數(shù)據(jù)庫中壓根不存在永遠(yuǎn)無法回填緩存。對業(yè)務(wù)的影響也完全不同擊穿恢復(fù)后緩存會被重新回填系統(tǒng)能自動恢復(fù)穿透則會持續(xù)打數(shù)據(jù)庫直到流量停止或采取了額外防護(hù)。1.3 緩存雪崩大量Key同時過期導(dǎo)致緩存層整體失效雪崩的覆蓋面比擊穿大得多。如果一批緩存Key設(shè)置的過期時間相同比如都是整點(diǎn)過期、都是30分鐘過期到了某個時間點(diǎn)這大批Key會一起失效。此時請求全部回源數(shù)據(jù)庫數(shù)據(jù)庫壓力瞬間達(dá)到峰值很容易觸發(fā)連接池耗盡、慢查詢堆積、主從延遲等一系列連鎖反應(yīng)。我見過一個典型事故運(yùn)營人員把一批活動頁面的緩存過期時間統(tǒng)一設(shè)置為600秒結(jié)果每天上午10點(diǎn)整這批頁面同時刷新數(shù)據(jù)庫在10點(diǎn)整那一分鐘內(nèi)的QPS比平時翻了20倍直接宕機(jī)。更麻煩的是Redis中大量Key失效后如果緩存服務(wù)本身也扛不住回源請求比如Redis線程被阻塞故障會從數(shù)據(jù)庫向上蔓延形成級聯(lián)效應(yīng)。還有一種雪崩場景不是Key過期導(dǎo)致的而是Redis實(shí)例宕機(jī)。Redis掛了之后所有請求直接繞過緩存打到數(shù)據(jù)庫這種物理級別的雪崩往往比Key過期更致命因?yàn)榫彺鎸用嬉呀?jīng)完全沒有保護(hù)能力。1.4 三兄弟對比一張表看懂差異維度緩存穿透緩存擊穿緩存雪崩觸發(fā)場景查詢不存在的Key單個熱點(diǎn)Key過期大量Key同時過期 / Redis宕機(jī)數(shù)據(jù)真實(shí)性數(shù)據(jù)庫不存在數(shù)據(jù)庫存在數(shù)據(jù)庫存在影響范圍單個無效請求持續(xù)不斷單個Key高并發(fā)瞬間多個Key全局性壓力恢復(fù)方式無需回填需要攔截回填緩存自動恢復(fù)回填大量緩存耗時較長核心防御布隆過濾器、空值緩存互斥鎖、邏輯過期過期時間隨機(jī)、多級緩存、高可用分清這三種場景之后下面我逐個講對應(yīng)的防御方案每一步都會給出可以直接抄作業(yè)的實(shí)現(xiàn)。2. 布隆過濾器攔截穿透請求的第一道閘門布隆過濾器的核心價值在于用極低的內(nèi)存成本快速判斷一個Key“一定不存在”。它允許誤判存在但不允許誤判不存在。也就是說如果布隆過濾器說“這個Key不存在”那它一定不存在可以安心攔截如果它說“可能存在”則需要放行到后續(xù)邏輯去驗(yàn)證。2.1 布隆過濾器的原理和數(shù)學(xué)直覺布隆過濾器的底層是一個位數(shù)組bit數(shù)組 一組哈希函數(shù)。插入一個Key時用k個哈希函數(shù)分別計算得到k個位置把這些位置上的bit全部置為1查詢一個Key時同樣計算k個位置如果所有位置都是1則認(rèn)為“可能存在”只要有一個位置是0就認(rèn)為“一定不存在”。為什么說“可能存在”因?yàn)楣Ｅ鲎病２煌琄ey可能映射到相同的位置導(dǎo)致某個Key雖然沒有插入過但它的所有哈希位置都已經(jīng)被其他Key置為1這就產(chǎn)生了誤判。誤判率可以估算經(jīng)典公式是誤判率 p ≈ (1 - e^(-kn/m))^k其中n是預(yù)計插入的元素數(shù)量m是位數(shù)組長度k是哈希函數(shù)個數(shù)。實(shí)際操作中可以先預(yù)估n然后根據(jù)可接受的誤判率p反推m和k。常用的簡化公式是m -n * ln(p) / (ln2)^2 k m/n * ln2舉個例子。假設(shè)預(yù)計插入100萬個訂單號希望誤判率控制在1%代入公式m約等于958萬位換算成字節(jié)約1.2MBk約等于7。也就是說用1.2MB內(nèi)存和一億分之一的誤判概率就能擋住幾乎所有不存在的Key查詢。這個性價比非常高。2.2 布隆過濾器在生產(chǎn)環(huán)境中的三種落地姿勢第一Guava的BloomFilter。適合單機(jī)應(yīng)用數(shù)據(jù)在本地內(nèi)存中加載后只能單機(jī)判斷。對于部署在多個實(shí)例上的服務(wù)每個實(shí)例都需要各自構(gòu)建一份適合Key集合相對固定、實(shí)例數(shù)不多、數(shù)據(jù)量在百萬級的場景。BloomFilterString filter BloomFilter.create( Funnels.stringFunnel(StandardCharsets.UTF_8), 1_000_000, // 預(yù)計元素數(shù) 0.01); // 期望誤判率 filter.put(order_123456); boolean mightContain filter.mightContain(order_987654);第二Redis的布隆過濾器插件。Redis 4.0之后可以通過模塊方式安裝bf命令常見的是RedisBloom模塊。這種方式的好處是過濾器數(shù)據(jù)集中在Redis中所有應(yīng)用實(shí)例共享同一個判斷結(jié)果不必每個實(shí)例各自構(gòu)建。缺點(diǎn)是Redis需要額外加載模塊有一定的運(yùn)維成本。BF.RESERVE order_filter 0.01 1000000 BF.ADD order_filter order_123456 BF.EXISTS order_filter order_987654第三基于Redis字符串位圖手動實(shí)現(xiàn)。用SETBIT和GETBIT命令來模擬位數(shù)組操作代碼可控性強(qiáng)不依賴額外模塊適合已有Redis集群不想引入新組件的情況。不過哈希函數(shù)需要自己在代碼里實(shí)現(xiàn)處理起來稍微繁瑣一些。2.3 布隆過濾器誤判的后果和處理方法誤判意味著某些不存在的Key會被放行到數(shù)據(jù)庫。雖然誤判率可以控制在1%甚至更低但1%的無效回源請求在千萬級QPS下依然很可觀。所以要組合使用布隆過濾器做第一層攔截攔截掉99%的穿透流量剩下1%的漏網(wǎng)之魚再用空值緩存方案兜底——把查詢結(jié)果為null的Key也緩存起來設(shè)置一個較短的過期時間比如60秒。這樣即使布隆過濾器誤判放行第二次相同請求也會被空值緩存擋住。我在實(shí)際項(xiàng)目中推薦的組合邏輯是請求進(jìn)來 - 布隆過濾器判斷不存在 - 直接返回空結(jié)果 請求進(jìn)來 - 布隆過濾器判斷可能存在 - 查Redis緩存 - 命中直接返回 請求進(jìn)來 - 布隆過濾器判斷可能存在 - 查Redis緩存未命中 - 查數(shù)據(jù)庫 - 回填緩存含空值緩存注意布隆過濾器無法刪除元素。如果想刪除舊數(shù)據(jù)只能用“定期重建過濾器”的方式或者選擇支持刪除的變體比如布谷鳥過濾器但這個變體的實(shí)現(xiàn)復(fù)雜度會明顯上升。3. 互斥鎖與邏輯過期擊穿防御的兩條實(shí)戰(zhàn)路線擊穿的核心矛盾是熱點(diǎn)Key過期后一瞬間有大量并發(fā)請求同時回源。要解決這個問題思路很簡單——讓這些請求不要同時回源而是只放一個請求去數(shù)據(jù)庫重建緩存其余請求要么等要么拿舊值。3.1 互斥鎖方案的實(shí)現(xiàn)細(xì)節(jié)互斥鎖的思路是當(dāng)緩存未命中時不是立刻查數(shù)據(jù)庫而是先嘗試獲取一把分布式鎖。拿到鎖的請求去查數(shù)據(jù)庫并回填緩存其他請求在鎖上等待然后重新讀取緩存。這里的關(guān)鍵問題是用哪種分布式鎖等待多久鎖何時釋放我推薦直接用Redis的SET NX PX命令實(shí)現(xiàn)避免引入額外的ZooKeeper或Etcd依賴畢竟Redis已經(jīng)在鏈路里了。// 嘗試獲取鎖設(shè)置5秒超時 String token UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lock:hot_key, token, Duration.ofSeconds(5)); if (Boolean.TRUE.equals(locked)) { try { // 二次檢查緩存防止在等鎖期間緩存已經(jīng)被其他線程重建 Object cached redisTemplate.opsForValue().get(key); if (cached ! null) { return cached; } // 查數(shù)據(jù)庫 Object data queryFromDatabase(key); redisTemplate.opsForValue().set(key, data, Duration.ofSeconds(600)); return data; } finally { // 釋放鎖時需要校驗(yàn)持有者身份防止誤刪其他線程的鎖 String lockValue redisTemplate.opsForValue().get(lock:hot_key); if (token.equals(lockValue)) { redisTemplate.delete(lock:hot_key); } } } else { // 沒拿到鎖休眠一小段時間后重試 Thread.sleep(50); return getFromCacheOrDb(key); // 遞歸重試注意控制重試次數(shù) }這段代碼有幾個細(xì)節(jié)值得展開。關(guān)于鎖的持有者校驗(yàn)釋放鎖時如果直接delete可能把其他線程剛獲取的新鎖誤刪。比如線程A的鎖5秒超時自動釋放線程B獲取了新鎖此時線程A的finally塊執(zhí)行delete就會把B的鎖刪掉導(dǎo)致B的互斥失效。所以釋放前必須比對value值我這里用UUID做標(biāo)識只有持有者自己才能刪除。關(guān)于等待和重試沒拿到鎖就短睡眠然后遞歸重試但這個遞歸需要加次數(shù)限制。我見過一個線上問題熱點(diǎn)Key的數(shù)據(jù)庫查詢特別慢超過鎖的5秒超時第一個線程的鎖已經(jīng)自動失效了第二個線程拿到鎖又開始查庫結(jié)果多個線程實(shí)際上都在查庫互斥完全失效。所以鎖超時時間必須大于“建緩存”的耗時通常建議壓測后確定一般取數(shù)據(jù)庫查詢耗時的3-5倍。關(guān)于JVM內(nèi)鎖的補(bǔ)充如果所有請求都落在同一個Java進(jìn)程內(nèi)用JDK內(nèi)置的synchronized或ReentrantLock做本地鎖就夠了性能遠(yuǎn)高于分布式鎖。只有當(dāng)服務(wù)是集群部署時才需要跨進(jìn)程的分布式鎖。我常用的優(yōu)化方案是“本地鎖分布式鎖”兩級結(jié)合先獲取本地鎖同一個實(shí)例內(nèi)的并發(fā)先被本地鎖擋掉只有不同實(shí)例之間才需要競爭分布式鎖。這種方式能大幅減少Redis鎖請求的壓力。3.2 邏輯過期方案用舊數(shù)據(jù)扛過真空期互斥鎖的痛點(diǎn)是如果熱點(diǎn)Key過期瞬間有大量請求在等待響應(yīng)時間會變長重試也會占用線程資源。邏輯過期方案則完全不同——它不存在“緩存過期”的概念。具體做法是緩存數(shù)據(jù)中額外存儲一個邏輯過期時間字段但Redis中的Key本身不過期或者設(shè)置一個很長的物理過期時間。請求讀取到數(shù)據(jù)后先判斷邏輯過期時間是否已到。如果沒過期直接返回如果已過期則嘗試獲取互斥鎖獲取成功后開啟一個異步線程去數(shù)據(jù)庫更新緩存當(dāng)前請求則直接返回“過期的舊數(shù)據(jù)”。public Object getProductInfo(String key) { // 從緩存讀取Redis中的Key永不過期 String json redisTemplate.opsForValue().get(key); if (json null) { return null; // 理論上這種情況非常少Key被手動清理了 } CacheEntry entry JSON.parseObject(json, CacheEntry.class); if (entry.getExpireTime() System.currentTimeMillis()) { return entry.getData(); // 邏輯時間未過期直接返回 } // 邏輯過期嘗試獲取鎖異步刷新 if (tryGetLock(key)) { try { // 異步更新緩存 executorService.submit(() - { Object data queryFromDatabase(key); String newJson JSON.toJSONString(new CacheEntry(data, System.currentTimeMillis() 600_000)); redisTemplate.opsForValue().set(key, newJson); }); } finally { releaseLock(key); } } // 未拿到鎖的請求直接返回舊數(shù)據(jù) return entry.getData(); }這個方案的核心優(yōu)勢是請求永遠(yuǎn)都不會因?yàn)榫彺孢^期而等待響應(yīng)時間穩(wěn)定。核心缺點(diǎn)是在緩存異步更新的窗口期內(nèi)用戶看到的是舊數(shù)據(jù)。對于實(shí)時性要求不高的場景比如商品詳情、文章內(nèi)容、配置信息這個缺點(diǎn)完全可以接受。但如果數(shù)據(jù)是余額、庫存這種強(qiáng)一致要求的數(shù)據(jù)就不能用邏輯過期。這里有一個生產(chǎn)環(huán)境常見的坑異步線程池如果處理不過來緩存永遠(yuǎn)不更新舊數(shù)據(jù)會一直返回。所以要給這個線程池加上合理的隊(duì)列大小、拒絕策略和監(jiān)控報警。我一般用獨(dú)立線程池核心線程數(shù)和最大線程數(shù)根據(jù)數(shù)據(jù)庫能承受的并發(fā)來定同時監(jiān)控隊(duì)列深度超過閾值就報警。4. 雪崩防御多級緩存與過期時間的藝術(shù)雪崩的殺傷力在于覆蓋面大動輒幾十上百個Key同時失效。防御思路也分兩條一是讓失效時間分散二是讓數(shù)據(jù)庫上面不止緩存一道防線。4.1 過期時間的隨機(jī)化與業(yè)務(wù)錯峰最基礎(chǔ)的方案是把固定的過期時間改成“基礎(chǔ)過期時間隨機(jī)偏移量”。比如原來統(tǒng)一3600秒現(xiàn)在改成“3600 隨機(jī)數(shù)60~600秒”。這個策略在代碼里改動最小卻能顯著降低同時失效的概率。基礎(chǔ)時間 隨機(jī)偏移 實(shí)際過期時間 3600 random(60, 600) 3660~4200秒要注意的一點(diǎn)是不要所有Key都用一個隨機(jī)算法生成完全隨機(jī)的過期時間那樣會導(dǎo)致緩存命中率下降。更好的做法是“按業(yè)務(wù)分組打散”。比如活動頁面的Key集中在300~600秒隨機(jī)商品詳情的Key集中在3600~7200秒隨機(jī)這樣同類Key的過期時間大致在一個接近的區(qū)間但具體時間點(diǎn)錯開既保持了緩存效果又避免了集中失效。另一個工程上的細(xì)節(jié)很多團(tuán)隊(duì)用同一個RedisTemplate的set(key, value, time)方法設(shè)置緩存如果key的命名規(guī)則里包含業(yè)務(wù)前綴可以通過前綴來配置不同的隨機(jī)范圍。我習(xí)慣在緩存工具類中維護(hù)一個過期時間策略表用Map維護(hù)前綴和隨機(jī)范圍新增緩存場景時只需要加一行配置而不需要到處改業(yè)務(wù)代碼。4.2 多級緩存把壓力分散到更靠近用戶的地方當(dāng)Redis整實(shí)例宕機(jī)時隨機(jī)化過期時間完全失效。這時真正能扛住的是多級緩存架構(gòu)。常見的分級是本地緩存Caffeine - Redis緩存 - 數(shù)據(jù)庫。本地緩存放在應(yīng)用進(jìn)程內(nèi)讀寫納秒級不依賴網(wǎng)絡(luò)。即使Redis掛了只要本地緩存還有數(shù)據(jù)請求就不會打到數(shù)據(jù)庫。這里最常用的組件是Caffeine它支持基于時間的過期策略和基于大小的淘汰策略。CacheString, Object localCache Caffeine.newBuilder() .maximumSize(10_000) // 最多緩存1萬個Key .expireAfterWrite(Duration.ofSeconds(30)) // 寫入30秒后過期 .build();讀流程變成讀取本地緩存 - 未命中則讀取Redis - 未命中則查數(shù)據(jù)庫 - 回填兩級緩存這里強(qiáng)調(diào)一個關(guān)鍵點(diǎn)本地緩存的過期時間必須比Redis短。否則本地緩存長期持有舊數(shù)據(jù)Redis中的數(shù)據(jù)更新后本地緩存感知不到就會出現(xiàn)數(shù)據(jù)不一致。常見的設(shè)置為本地緩存30秒Redis緩存10-15分鐘。這樣Redis更新后最多30秒內(nèi)本地緩存會過期重新從Redis拉取新數(shù)據(jù)。多級緩存最大的槽點(diǎn)是數(shù)據(jù)一致性。如果后臺更新了數(shù)據(jù)庫需要主動失效Redis中的舊緩存但本地緩存分布在每個應(yīng)用實(shí)例中無法統(tǒng)一失效。我的實(shí)踐經(jīng)驗(yàn)是對一致性要求不高的讀取場景接受本地緩存30秒的短時不一致對一致性要求較高的場景不要加本地緩存直接走Redis。4.3 Redis高可用的兜底還有一個層面需要重視Redis本身的可用性。Redis主從切換、哨兵、集群模式都是基礎(chǔ)設(shè)施層面的雪崩防御。但要注意的是即便Redis是高可用的主從切換的那幾秒內(nèi)緩存寫入依然可能失敗。所以在業(yè)務(wù)代碼中寫緩存必須捕獲異常并降級不能因?yàn)镽edis報錯而影響主流程。try { redisTemplate.opsForValue().set(key, value, timeout); } catch (Exception e) { // Redis異常時降級本次不寫緩存下次請求繼續(xù)嘗試 log.warn(write redis failed, e); }同理讀緩存也要做降級。如果Redis讀超時不要拋異常讓請求失敗而是直接返回null并進(jìn)入數(shù)據(jù)庫查詢流程。雖然這會加重數(shù)據(jù)庫壓力但至少業(yè)務(wù)是可用的配合熔斷機(jī)制可以控制住影響范圍。5. 一套完整的防御體系高并發(fā)讀接口的落地框架前面分別講了穿透、擊穿、雪崩的防御手段但真實(shí)的生產(chǎn)環(huán)境要的是把這些手段組合成一個統(tǒng)一的讀接口框架而不是在每一個業(yè)務(wù)代碼里東拼西湊。我構(gòu)建過一套比較通用的“四級防御”讀接口在這里給出完整的設(shè)計。5.1 四級防御鏈路拆解整個讀請求的流程可以分為四層第一層本地緩存。Caffeine承載過期時間30秒。這一層的目的是扛住極端QPS下對Redis的壓力。如果本地緩存命中整體響應(yīng)時間在毫秒級。第二層布隆過濾器。判斷Key是否可能存在。如果不存在直接返回空結(jié)果或緩存中的空標(biāo)記杜絕穿透流量進(jìn)入數(shù)據(jù)庫。布隆過濾器可以放在RedisRedisBloom模塊中也可以放在本地Guava根據(jù)數(shù)據(jù)量權(quán)衡。第三層Redis緩存。承載主要的緩存命中流量過期時間根據(jù)業(yè)務(wù)配置采用基礎(chǔ)時間隨機(jī)偏移。這一層是系統(tǒng)的主力緩存層。第四層數(shù)據(jù)庫。只有前面三層全部未命中才會到達(dá)這一層。到達(dá)這一層時還要用互斥鎖控制并發(fā)回源的數(shù)量保證同時只有少數(shù)請求在查庫。5.2 統(tǒng)一的讀接口模板代碼下面是我常用的一個泛型化模板的骨架業(yè)務(wù)方只需要傳入Key生成函數(shù)和數(shù)據(jù)庫查詢函數(shù)public T T queryWithDefense(String key, FunctionString, T dbQuery, ClassT clazz) { // 本地緩存1Caffeine Object local localCache.getIfPresent(key); if (local ! null) { return (T) local; } // 防線2布隆過濾器不存在直接返回 if (!bloomFilter.mightContain(key)) { return null; } // 防線3Redis緩存 String json redisTemplate.opsForValue().get(key); if (json ! null) { T data JSON.parseObject(json, clazz); localCache.put(key, data); // 回填本地緩存 return data; } // 防線4互斥鎖控制回源 T data loadFromDbWithLock(key, dbQuery, clazz); if (data ! null) { localCache.put(key, data); } return data; }要注意的是這個模板把布隆過濾器的判斷放在Redis緩存之前。這么做的原因是布隆過濾器的查詢時間比較快而且如果它判斷Key不存在就沒有必要再去Redis執(zhí)行一次G一邊GET。另一個細(xì)節(jié)如果業(yè)務(wù)允許一定程度的延遲這里的“防線2”可以在本地緩存中實(shí)現(xiàn)但如果布隆過濾器數(shù)據(jù)量較大本地內(nèi)存撐不住就必須放在Redis中。5.3 實(shí)測效果與調(diào)優(yōu)參數(shù)參考我把這套框架用在一個商品詳情接口上壓測結(jié)果供大家參考接口原生QPS約800數(shù)據(jù)庫單機(jī)可承受約2000 QPS的查詢。加四級防御后Jmeter壓測線程數(shù)從100調(diào)到1000數(shù)據(jù)庫實(shí)際接收的查詢QPS穩(wěn)定在30左右接口P99響應(yīng)時間從40ms降到了12ms。主要參數(shù)配置是這樣的參數(shù)值說明本地緩存過期時間30秒必須小于Redis緩存過期時間本地緩存最大條目10000防止內(nèi)存溢出需要根據(jù)Heap大小調(diào)整Redis緩存過期時間600秒隨機(jī)120秒兼顧命中率和防雪崩布隆過濾器預(yù)計元素量實(shí)際數(shù)據(jù)量×1.1留出10%余量布隆過濾器誤判率0.01取值越低內(nèi)存越大鎖超時時間5秒大于數(shù)據(jù)庫慢查詢耗時異步刷新線程池核心4最大8隊(duì)列1000根據(jù)數(shù)據(jù)庫能力配置這個配置不是固定不變的僅供參考。核心原則是數(shù)據(jù)庫回源量必須壓到數(shù)據(jù)庫能承受的范圍以內(nèi)同時保證緩存命中率在95%以上。6. 常見問題與排查技巧實(shí)錄在實(shí)際維護(hù)這套體系的過程中我踩過不少坑也總結(jié)了一些排查路徑。單獨(dú)拎出來說一遍可能比上面那些代碼更有價值。6.1 布隆過濾器誤判偏高怎么辦誤判率升高先別急著調(diào)大位數(shù)組。排查一下是不是數(shù)據(jù)量增長超出預(yù)期導(dǎo)致初始化的n值過小。比如你初始化的預(yù)計元素量是100萬實(shí)際寫進(jìn)了500萬誤判率會急劇升高。解決辦法是監(jiān)控過濾器中的BF.INFORedisBloom或者布隆過濾器當(dāng)前元素數(shù)的估算值超過預(yù)計量的80%就觸發(fā)自動重建或者提前把預(yù)計量設(shè)大一點(diǎn)。還有一個容易忽略的問題業(yè)務(wù)代碼中對Key的序列化方式不統(tǒng)一。有的地方用String有的地方用DigestUtils.md5DigestAsHex做了哈希如果Key的格式不統(tǒng)一布隆過濾器中的數(shù)據(jù)和查詢的數(shù)據(jù)無法對應(yīng)會產(chǎn)生大量“假誤判”。排查時可以先打日志確認(rèn)同一個Key在寫入和查詢時經(jīng)過的字符串是否完全一致。6.2 互斥鎖失效緩存被重復(fù)重建鎖失效最典型的場景是持鎖線程執(zhí)行時間超過了鎖的自動過期時間。鎖被Redis自動刪除后其他線程又拿到新鎖造成多個線程同時查庫。排查時看日志里“acquire lock”和“release lock”的間隔如果經(jīng)常接近鎖超時時間說明建緩存過程太慢需要優(yōu)化數(shù)據(jù)庫查詢或者把鎖的超時時間拉長。還有一個更隱蔽的問題鎖的key設(shè)置了過期時間但釋放鎖時用delete命令如果恰好在這個時刻鎖已經(jīng)過期刪除操作就會把別人剛創(chuàng)建的新鎖刪掉。前面代碼里面已經(jīng)提到解決方案就是用UUID作為鎖的value并校驗(yàn)后再刪。這個細(xì)節(jié)能擋住很多人都會踩的坑。6.3 多級緩存數(shù)據(jù)不一致如何緩解多級緩存一定會面臨不一致的問題。Redis更新了本地緩存可能還是舊數(shù)據(jù)數(shù)據(jù)庫更新了Redis緩存也還是舊數(shù)據(jù)。我的建議是不要追求強(qiáng)一致而是把一個可接受的不一致時間明確寫進(jìn)文檔。對于主動更新的場景可以在更新數(shù)據(jù)庫后先刪Redis緩存再通過延遲雙刪1秒后再次刪除來清理可能被讀請求重新寫入的舊緩存。本地緩存這邊如果框架支持消息通知可以通過Redis的Pub/Sub廣播一個“清本地緩存”的消息如果沒條件就接受它最多30秒的過期時間。重要提示多級緩存的一致性考驗(yàn)的不是技術(shù)而是業(yè)務(wù)容忍度。設(shè)計架構(gòu)前先和業(yè)務(wù)方確認(rèn)數(shù)據(jù)更新后最多可以接受多少秒的延遲把這個數(shù)字寫清楚比你用再高級的組件都重要。6.4 緩存回填風(fēng)暴的預(yù)防當(dāng)大量緩存同時失效時回填過程本身也會造成數(shù)據(jù)庫壓力。除了隨機(jī)過期時間以外還有個技巧是“回填節(jié)流”——不是所有請求都去數(shù)據(jù)庫回填而是只讓一部分請求去查詢其他請求直接返回默認(rèn)值或空數(shù)據(jù)。比如用互斥鎖保證同一時刻只有一個請求回填或者用一個“回填信號量”控制全局的最大回填并發(fā)數(shù)。我在高并發(fā)場景下還用過一種“漸進(jìn)式回填”緩存失效時返回的舊數(shù)據(jù)里帶一個refresh_after字段表示“這個數(shù)據(jù)最多再服務(wù)多久”。到達(dá)這個時間后只允許一個異步任務(wù)去刷新而同步請求永遠(yuǎn)拿舊數(shù)據(jù)。這是邏輯過期方案的變種非常適用于數(shù)據(jù)更新不頻繁但讀取量極大的場景。7. 這些方案的邊界和取舍布隆過濾器、互斥鎖、多級緩存這些方案都不是銀彈它們有各自的邊界。我在實(shí)際項(xiàng)目中反復(fù)調(diào)整過很多次逐漸摸索出一些取舍的經(jīng)驗(yàn)。布隆過濾器最大的邊界是它只能用于“判斷存在性”不適合作為唯一的穿透防御。如果業(yè)務(wù)中合法請求都是“近期創(chuàng)建的數(shù)據(jù)”那么布隆過濾器很快就會被塞滿重建成本很高。這種情況下空值緩存也許更直接。兩種方案可以組合空值緩存放Redis布隆過濾器放本地前者兜底后者攔截絕大多數(shù)惡意流量。互斥鎖的邊界在于它本質(zhì)上是在“用性能換一致性”——請求需要等待必然增加延遲。如果熱點(diǎn)Key的過期頻率很高比如每分鐘都過期那么鎖競爭本身就會成為新的瓶頸。這時候邏輯過期方案更合適因?yàn)樗鼛缀鯖]有鎖等待。多級緩存的邊界在于“數(shù)據(jù)一致性”和“內(nèi)存成本”。本地緩存的引入意味著每個應(yīng)用實(shí)例要額外占用內(nèi)存如果緩存條目太大會導(dǎo)致JVM GC壓力上升。選擇哪些數(shù)據(jù)進(jìn)本地緩存、哪些只走Redis需要按數(shù)據(jù)熱度來分。熱度高的、讀取量大的、一致性要求低的數(shù)據(jù)才適合放本地。我個人的原則是先解決主要矛盾。如果問題是穿透流量大優(yōu)先上布隆過濾器如果問題是熱點(diǎn)數(shù)據(jù)偶爾過期導(dǎo)致抖動優(yōu)先上互斥鎖如果問題是周期性雪崩優(yōu)先隨機(jī)化過期時間。不要一上來就上一個全量的“緩存防御全家桶”復(fù)雜度會翻倍排查問題的難度也會翻倍。8. 一次真實(shí)事故的復(fù)盤從報警到修復(fù)的完整思路最后分享一次我親身經(jīng)歷的事故把前面這些理論串起來看效果會更好。某次大促預(yù)熱期凌晨兩點(diǎn)監(jiān)控突然報警數(shù)據(jù)庫CPU打滿慢查詢暴漲。查看Redis的hit ratio從平時的98%掉到了76%。第一反應(yīng)是查RedisKey的過期情況發(fā)現(xiàn)大量活動相關(guān)的Key同時過期——運(yùn)營同學(xué)在后臺定時任務(wù)里批量刷新活動數(shù)據(jù)刷新代碼統(tǒng)一設(shè)置的過期時間是300秒而定時任務(wù)每5分鐘執(zhí)行一次相當(dāng)于每300秒就有幾百個Key同時被重建。解決思路分了三步第一步止血。臨時把定時任務(wù)的刷新邏輯改掉刷新完成后不刪舊緩存而是先更新數(shù)據(jù)庫再通過異步任務(wù)在后臺批量重寫緩存讓緩存過期時間錯開。這一步花了5分鐘數(shù)據(jù)庫壓力立即回落。第二步治理。把活動緩存代碼統(tǒng)一改成隨機(jī)過期時間并且加了一個開關(guān)如果某個批次Key的數(shù)量超過閾值就隨機(jī)挑選其中一半先刷新剩下的延遲30秒再刷新避免瞬時并發(fā)回填。第三步預(yù)防穿透。大促當(dāng)天存在大量用戶反復(fù)刷新不存在的活動頁面布隆過濾器提前添加了所有活動ID的集合無效請求在過濾器就直接被攔掉。事故復(fù)盤后我意識到一個核心問題很多緩存故障不是技術(shù)方案不行而是業(yè)務(wù)側(cè)的定時任務(wù)、批量操作沒有考慮緩存失效的“共振效應(yīng)”。技術(shù)防御是必要的但更重要的是在業(yè)務(wù)流程中加入緩存意識——比如批量更新數(shù)據(jù)的任務(wù)一定要把“集中過期”作為一項(xiàng)風(fēng)險來評估。這套防御體系我的建議是你不用全上根據(jù)自己的業(yè)務(wù)體量從布隆過濾器或互斥鎖選一個開始逐步疊加。先把最痛的那一個問題解決了再考慮引入更多組件。緩存這層看上去簡單但真正要扛住高并發(fā)那些“緩存失效瞬間”的處理才見功底。