高并發(fā)場景下緩存穿透和緩存擊穿是每一套基于Redis的業(yè)務系統(tǒng)都繞不開的兩個經(jīng)典敵人。面試八股文里它們是高頻考題生產(chǎn)環(huán)境里它們更是實打實出過事故的。我經(jīng)歷過一次凌晨大促時熱點商品ID被攻擊者批量刷不存在數(shù)據(jù)DB連接池被打滿核心接口超時率飆升當時我們的緩存層幾乎沒有防御能力純靠數(shù)據(jù)庫硬扛。那之后我們團隊花了三個迭代把緩存防護邏輯從散落的業(yè)務代碼里抽出來封裝成一套通用工具覆蓋布隆過濾器攔截、分布式鎖重建、本地緩存兜底三條鏈路。這篇文章就把這套封裝方案的完整思路、代碼細節(jié)、參數(shù)計算和踩坑記錄整理出來給同樣在治理緩存問題的同學一個可落地的參考。這套封裝方案適合正在維護高并發(fā)服務的后端開發(fā)者尤其適合那些已經(jīng)接入了Redis、但還在用最原始的check-then-act方式處理緩存并且被穿透和擊穿過幾次、想系統(tǒng)性解決這個問題的團隊。內(nèi)容不要求你有多深的分布式基礎只要會用Spring Boot、寫過RedisTemplate就能跟上我會把每一步的原理和取舍邏輯都講明白。1. 穿透和擊穿先分清敵人再動手很多團隊一上來就想著寫布隆過濾器、寫分布式鎖但連自己面對的是穿透還是擊穿都還沒分清。兩種問題表現(xiàn)相似都是“緩存里查不到請求打到DB”但根因、攻擊特征和解決方案完全不同混在一起治理必然事倍功半。1.1 兩種問題的核心差異緩存穿透查的是數(shù)據(jù)庫中壓根不存在的數(shù)據(jù)。緩存里沒有數(shù)據(jù)庫里也沒有于是每一次請求都老老實實打到DB查了個寂寞。這通常是惡意攻擊者用隨機ID、自增負數(shù)、不存在的手機號等批量刷接口瞬間流量全部穿透緩存直達存儲層。更麻煩的是因為DB里沒有數(shù)據(jù)正常邏輯下你不會寫緩存所以穿透是“每一次都發(fā)生”的不像擊穿只是窗口期那幾秒。緩存擊穿針對的是某個熱點key。這個key平時被大量線程并發(fā)讀取比如秒殺商品的庫存、爆款視頻的播放量、明星動態(tài)的熱度值Redis里明明有緩存但緩存突然過期了。在過期的那一瞬間所有并發(fā)請求同時發(fā)現(xiàn)緩存miss于是一股腦沖進DB查同一行數(shù)據(jù)數(shù)據(jù)庫單key的QPS瞬間飆升。注意擊穿的場景是“數(shù)據(jù)存在、緩存短暫失效”而穿透是“數(shù)據(jù)本身不存在”。順便說一句緩存雪崩大量key同時過期導致大面積DB壓力是另一個問題它的核心是“批量失效”而不是“單點失效”治理手段也偏重在過期時間上打散抖動。這篇文章的互斥鎖方案對雪崩幫不上什么忙但會在TTL策略里順帶提到一點免得大家混淆。1.2 為什么必須封裝而不是每個接口自己寫我在很多項目里看到過這樣的代碼每個Service層都有一段“先查緩存沒有就查庫再放緩存”的邏輯各自為政。你今天在這個接口加了布隆過濾器判斷明天那個接口漏了這個接口重建緩存時搶鎖了那個接口直接裸奔空值緩存有的做了、有的沒做TTL還各不相同。封裝的核心價值不在于省幾行代碼而在于把防御行為統(tǒng)一化。業(yè)務方只需要調用工具類的一個方法傳入key和加載函數(shù)工具內(nèi)部自動完成布隆過濾、緩存查詢、鎖保護、空值兜底、本地緩存降級這一整套動作。業(yè)務代碼里不再出現(xiàn)任何關于鎖、過濾器、TTL的細節(jié)改動也只需動工具層一處全鏈路生效。我們封裝之后新接口接入緩存防護的成本從半天降到十分鐘而且不會再出現(xiàn)“忘了加防護”這種低級事故。2. 方案選型三層防護的組合邏輯單獨用任何一種方案都有明顯短板我們的最終形態(tài)是布隆過濾器、分布式鎖、本地緩存三層配合各管一段。2.1 三層防護各自解決的問題第一層是布隆過濾器擋在查詢鏈路的最前端用極小的內(nèi)存代價攔截掉絕大多數(shù)“不存在key”的查詢這是對抗穿透的主力。它的特點是“寧可錯殺一千不可放過一個”也就是說它只會誤判“可能存在”但從來不會漏判“一定不存在”所以直接命中DB的查詢量被壓到極低。第二層是分布式鎖專門處理熱點key過期瞬間的并發(fā)重建問題。鎖保護下同一時刻只有一個線程去查DB并回填緩存其他線程等緩存就緒后直接讀這是對抗擊穿的主力。第三層是本地緩存Caffeine放在應用進程內(nèi)作為極端情況下的最后一道兜底。當Redis不可用或者剛發(fā)生緩存重建時本地緩存還能提供一份舊數(shù)據(jù)避免所有請求瞬間壓到DB。這一層我們的定位是“容災”不追求強一致只求降級時用戶還能看到數(shù)據(jù)。這三層不是疊加出來的是從實際故障場景里反推出來的。最早我們只有分布式鎖后來發(fā)現(xiàn)攻擊者用隨機ID刷穿透時鎖根本沒用——因為key都不一樣鎖粒度根本不收斂必須靠布隆過濾器在前面把大部分流量擋掉。后來又發(fā)現(xiàn)DB連接池被打滿時即使Redis恢復了短期內(nèi)流量涌入也會讓服務抖動本地緩存才補上來。2.2 為什么不只做空值緩存很多人問緩存穿透最簡單的方法不就是把空結果也緩存起來嗎確實對“固定ID不存在”的場景空值緩存很有效查詢DB發(fā)現(xiàn)沒數(shù)據(jù)就把null塞進Redis設個一兩分鐘TTL下次同key查詢直接命中空值。但請注意惡意穿透的攻擊特征是“隨機key”今天刷A明天刷B每個key都是新的空值緩存根本攔不住——因為每來一個新key你都得先查一遍DB才知道它是空的然后才把它緩存起來。攻擊者只要保持每秒幾萬個新key的速率DB依然被打穿而且Redis里還會堆積大量無意義的空值緩存白白消耗內(nèi)存。布隆過濾器則完全不同。它用固定的位數(shù)組存儲所有“可能存在”的key指紋占用空間是固定的跟已經(jīng)查詢了多少不存在的key無關。查詢時用哈希計算在位數(shù)組里找標記標記不存在就直接返回連DB都不碰。所以它對“隨機key批量穿透”這類攻擊有天然的過濾能力這是空值緩存做不到的。我們的實際做法是兩者結合布隆過濾器作為第一道閘過濾掉絕大多數(shù)不存在的key對于漏網(wǎng)之魚布隆過濾器誤判的少量key以及業(yè)務上合法但當前無數(shù)據(jù)的key再用空值緩存做第二道兜底?？罩礣TL設置得很短比如90秒既能擋住短時間內(nèi)的重復查詢又不會讓無效數(shù)據(jù)長期占用內(nèi)存。2.3 鎖方案為什么選Redisson而不是手寫setnx緩存擊穿的互斥鎖最樸素的做法是Redis的SETNX搶到鎖的線程查DB回填其他線程自旋等待。但手寫SETNX有一堆細節(jié)要處理鎖要設置過期時間防止持有鎖的線程宕機導致死鎖過期時間設多長很難拿捏設短了線程還沒查完DB鎖就釋放了設長了鎖故障時恢復慢還要考慮重入、鎖續(xù)期、釋放時誤刪別人的鎖。這些邊角問題在真實故障里全是坑。Redisson的RLock把這些都解決了通過看門狗機制自動續(xù)期默認每10秒檢查一次只要線程還在執(zhí)行就不斷續(xù)期避免鎖因業(yè)務執(zhí)行時間過長而提前釋放支持可重入同一線程可以重復獲取鎖釋放鎖時通過Lua腳本保證原子性只有持有者才能釋放。我們用Redisson后鎖相關的故障基本絕跡了這也是我強烈不建議手寫鎖的原因。2.4 為什么不用現(xiàn)成框架而選擇自研封裝市面上確實有現(xiàn)成的緩存框架比如JetCache、Spring Cache的Redis實現(xiàn)等它們大多提供了Cached注解和統(tǒng)一的緩存訪問入口。但我們的場景有幾個特殊需求第一需要和布隆過濾器深度集成大部分框架只是簡單的key-value存取過濾器要單獨在業(yè)務代碼里手動調用沒法統(tǒng)一第二需要熱點key的動態(tài)識別與續(xù)期框架層面很少內(nèi)置這種策略第三我們的調用形態(tài)非常靈活有些緩存是一段計算結果而不是簡單的DB行記錄需要傳入Supplier函數(shù)讓工具按需加載。自研封裝并不意味著從零造輪子。Redisson、Caffeine、布隆過濾器的實現(xiàn)都直接復用成熟組件我們只做組合和編排相當于把零件組裝成一臺專用機器這個成本比改造一個通用框架要低得多也更貼合團隊的業(yè)務習慣。3. 核心實現(xiàn)布隆過濾器攔截緩存穿透這塊是整套封裝里技術含量最高的部分布隆過濾器用最小的內(nèi)存擋住了最大量的無效請求。我盡量把原理、參數(shù)和代碼一次講透。3.1 布隆過濾器原理與參數(shù)計算布隆過濾器的核心是一個m位的位數(shù)組和k個哈希函數(shù)。插入一個key時用k個哈希函數(shù)分別計算得到k個下標把位數(shù)組對應位置置1。查詢一個key時同樣計算k個下標如果發(fā)現(xiàn)任何一個位置是0說明這個key一定不存在如果k個位置全是1說明可能存在也可能是因為多個不同key哈希重疊導致的誤判。它的優(yōu)勢是空間效率極高缺點是兩個一是不能刪除元素刪掉一個key后無法把對應位清零因為那一位可能被其他key共用二是存在誤判率p隨著插入數(shù)據(jù)量逼近容量上界誤判率會上升。參數(shù)計算有兩個核心公式我實際使用中每次都靠它們算容量位數(shù)組大小m - (n * ln(p)) / (ln(2))^2哈希函數(shù)個數(shù)k (m / n) * ln(2)舉個例子假設我們要存儲1000萬個合法key希望誤判率控制在1%計算得到m約等于9585萬bit換算成內(nèi)存大概是11.4MBk約等于7。這是一個非常劃算的代價——11MB內(nèi)存換來攔截99%的不存在key查詢而如果用空值緩存1000萬個key的存儲成本遠不止這個數(shù)。通過占位符可以快速驗證參數(shù)我寫了個簡單的在線計算腳本把n和p輸入進去直接出m和k避免人工計算出錯。3.2 基于Redisson布隆過濾器的初始化實現(xiàn)Redisson提供了現(xiàn)成的RBloomFilter實現(xiàn)配置方式很簡單。我們把它封裝在BloomFilterManager里啟動時自動初始化Component public class BloomFilterManager { private static final String BLOOM_FILTER_KEY bloom:user:id; private final RedissonClient redissonClient; public BloomFilterManager(RedissonClient redissonClient) { this.redissonClient redissonClient; } public RBloomFilterString getUserBloomFilter() { RBloomFilterString bloomFilter redissonClient.getBloomFilter(BLOOM_FILTER_KEY); // 這里傳入預期元素量和誤判率Redisson會自行計算位數(shù)組大小和哈希函數(shù)個數(shù) bloomFilter.tryInit(10_000_000L, 0.01); return bloomFilter; } }注意tryInit只會初始化一次第二次調用時如果參數(shù)一致就直接返回已有實例如果參數(shù)變了它會重新初始化這時候已插入的數(shù)據(jù)會丟失。所以這個參數(shù)一旦定下來盡量不要在生產(chǎn)環(huán)境修改。我踩過一次這個坑因為預估數(shù)據(jù)量翻倍了我把expectedInsertions改大了結果布隆過濾器被清空重建導致整條鏈路上所有穿透請求全部壓到DB好在當時是低峰期幾分鐘后數(shù)據(jù)重新加載完才恢復。3.3 合法數(shù)據(jù)集的加載策略布隆過濾器本身只是存儲指紋它不會平白知道哪些key是合法的。我們需要把合法的用戶ID、商品ID等預加載進去。這里有一個關鍵選擇全量加載還是異步增量加載。全量加載適合ID總量可控的場景比如用戶表幾百萬行啟動時從DB查一次全量ID批量填充到過濾器里。但要注意兩點第一批量加載時DB的IO壓力陡增建議分批查詢每批一萬條用線程池并發(fā)填充第二全量加載耗時可能較長這期間過濾器是不完整的如果服務已經(jīng)對外提供服務漏掉的部分會導致合法請求也被攔截。我們實際采用的是“全量加載 增量寫入”的組合。啟動時加載一次存量數(shù)據(jù)業(yè)務上每次新增合法ID時同步調用過濾器add方法補上。這要求所有寫入口共享同一個過濾管理器否則增量容易漏。還有一個容易被忽視的點如果業(yè)務上有刪除操作比如刪除用戶、下架商品布隆過濾器無法刪除對應指紋這些ID會一直殘留在過濾器里。對策是在過濾器判斷“可能存在”后業(yè)務查詢DB仍可能返回空這時用空值緩存兜底避免每次都穿透到DB。3.4 查詢鏈路上的攔截邏輯布隆過濾器攔截邏輯在封裝好的CacheService中統(tǒng)一實現(xiàn)業(yè)務方感知不到。核心代碼如下public T T getWithBloomFilter(String key, String bloomName, SupplierT dbLoader, Duration ttl) { RBloomFilterString bloomFilter getBloomFilter(bloomName); // 說明布隆過濾器判斷不存在直接返回null連Redis都不查 if (!bloomFilter.contains(key)) { return null; } // 布隆過濾器判斷可能存在繼續(xù)走緩存查詢鏈路 T value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } // 嘗試加鎖重建這一段在第四章詳細展開 return loadFromDbWithLock(key, dbLoader, ttl); }這里有一個性能細節(jié)contains判斷之前應該先拼好完整key并把業(yè)務前綴帶上。比如用戶ID是10001布隆過濾器的key應該是user:10001而不是裸的10001。因為不同業(yè)務可能共用同一個過濾器如果都用同一個那必須帶前綴區(qū)分也方便排查時直接看到key歸屬哪個模塊。我們在實踐中統(tǒng)一約定key的命名規(guī)則業(yè)務域:業(yè)務類型:ID布隆過濾器名稱也用這個前綴保證業(yè)務之間互不干擾。4. 核心實現(xiàn)分布式鎖與熱點緩存擊穿治理解決了穿透接下來是擊穿。熱點key在過期瞬間的并發(fā)重建是另一個必須用鎖才能壓住的場景。4.1 互斥鎖重建的完整流程當Redis緩存miss后我們不直接放所有線程進DB而是先搶分布式鎖。搶到鎖的線程才去查DB并回填緩存沒搶到鎖的線程等待一段時間后重查緩存。流程上有一個必須注意的關鍵點搶到鎖的線程在查DB之前要二次檢查緩存防止其他線程已經(jīng)重建完成這叫double check。我給出一個完整的循環(huán)版本避免用遞歸寫法導致棧溢出public T T loadFromDbWithLock(String key, SupplierT dbLoader, Duration ttl) { String lockKey lock: key; RLock lock redissonClient.getLock(lockKey); try { // 等待鎖最多3秒leaseTime設為-1表示交給看門狗自動續(xù)期 boolean locked lock.tryLock(0, -1, TimeUnit.SECONDS); if (locked) { try { // double check可能其他線程已經(jīng)在鎖內(nèi)重建好了 T cached redisTemplate.opsForValue().get(key); if (cached ! null) { return cached; } T value dbLoader.get(); if (value ! null) { redisTemplate.opsForValue().set(key, value, ttl); } else { // 空值也緩存防止穿透 redisTemplate.opsForValue().set(key, (T) NULL_PLACEHOLDER, Duration.ofSeconds(90)); } return value; } finally { lock.unlock(); } } else { // 沒搶到鎖小睡一會兒再查緩存最多重試3次 for (int i 0; i 3; i) { Thread.sleep(50L * (i 1)); T cached redisTemplate.opsForValue().get(key); if (cached ! null !NULL_PLACEHOLDER.equals(cached)) { return cached; } } // 重試3次仍未拿到數(shù)據(jù)說明DB很慢或鎖等待很久降級返回null由上層決定 return dbLoader.get(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); return dbLoader.get(); } }這段代碼里有幾個細節(jié)值得展開。tryLock第一個參數(shù)waitTime設成0意思是搶不到鎖立刻返回false不阻塞等待。正因為waitTime為0搶鎖失敗的線程會走for循環(huán)自己去重查緩存。這個策略比讓所有線程阻塞在鎖上更高效因為Redis重建通常是毫秒級等50毫秒再查基本都能拿到數(shù)據(jù)。重試3次后仍然沒拿到說明可能出現(xiàn)了極端情況比如DB查詢時間特別長。此時不能再無限等下去直接放行去查DB是降級策略同時上游要做好限流避免這少量請求把DB打崩。我建議這里記錄一條WARN日志方便后續(xù)排查為什么鎖內(nèi)重建這么慢。4.2 鎖的粒度和鎖內(nèi)耗時控制鎖的粒度是擊穿治理里最容易拍腦袋的地方。我們一開始偷懶把所有緩存重建操作都放到同一把鎖上鎖的字符串是lock:cache_rebuild。結果壓測時發(fā)現(xiàn)一個熱點key在重建時其他不相關的key查詢也被迫等待因為鎖沖突是全量的。這個方案在并發(fā)高的時候性能極差。正確的粒度是鎖的key必須包含業(yè)務keylock: 完整key讓每個業(yè)務key有一把獨立的鎖。不同key之間互不阻塞同一個key的并發(fā)請求才互斥這才是分布式鎖在緩存重建里的正確用法。鎖粒度越小并發(fā)度越高但也不能太小如果key本身包含用戶的個性化參數(shù)導致幾乎每個請求都不同鎖就形同虛設了。所以鎖粒度應該落在“熱點數(shù)據(jù)的集合”這個粒度上。鎖內(nèi)耗時要嚴格控制。鎖內(nèi)做了三件事查DB、序列化結果、寫入Redis。查DB是最不可控的一環(huán)如果SQL很慢鎖會一直持有其他線程等待也就越久。兩個優(yōu)化方向一是SQL本身加索引、限流、降級盡量保證單查詢在幾十毫秒內(nèi)返回二是給查詢加一個超時控制比如調用DB的SocketTimeout超過500毫秒直接拋異常讓失敗快速暴露不要吊死在慢SQL上。我們曾經(jīng)遇到過一個熱點key關聯(lián)的SQL因為多表聯(lián)查在大促時超過3秒導致鎖內(nèi)大量線程堆積直到我們把查詢拆成兩步緩存之后才好轉。4.3 熱點key的邏輯過期與主動續(xù)期互斥鎖解決了并發(fā)重建但還有一個場景它解決不了熱點key過期后的那幾百毫秒內(nèi)雖然只有重建的線程在查DB但其他線程都在自旋等待體驗上是有短暫卡頓的。更進一步如果這個熱點key被高頻訪問每次過期都觸發(fā)一次重建DB壓力依然不小。業(yè)界常用的做法是邏輯過期。物理上我們不刪除key也不設置Redis的天然TTL而是讓key永久存在但在value里包一層帶邏輯過期時間的包裝類。查詢時讀到包裝類發(fā)現(xiàn)邏輯過期了不直接刪除緩存而是返回舊值給調用方同時觸發(fā)異步線程去刷新DB數(shù)據(jù)并更新緩存。這樣做的好處是數(shù)據(jù)永遠是有的DB壓力從“每次過期瞬間的并發(fā)沖擊”變成了“后臺定時刷新”用戶體驗無感知。public class CacheWrapperT { private T value; private long logicalExpireTime; }代碼里實現(xiàn)也不復雜查詢發(fā)現(xiàn)邏輯過期后先返回舊值再提交一個異步任務去刷新。這里的核心取舍是數(shù)據(jù)的一致性和實時性舊值會存在一段時間如果業(yè)務對數(shù)據(jù)實時性要求不高比如商品詳情、排行榜、配置信息這種方案非常合適但如果要求強一致比如庫存扣減后的實時剩余量就不能用舊值還是得走互斥鎖同步重建。我們團隊的做法是把兩種策略都做成注解配置業(yè)務方按自己的數(shù)據(jù)屬性聲明。異步刷新也有一個細節(jié)多個線程同時觸發(fā)刷新會產(chǎn)生重復查DB所以刷新任務內(nèi)部也要加分布式鎖鎖內(nèi)先double check當前緩存是否已經(jīng)被其他線程更新過。4.4 本地緩存Caffeine兜底第三層是本地緩存我們引入Caffeine作為JVM內(nèi)的一級緩存。查詢鏈路變成先查Caffeinemiss后查RedisRedis miss后走互斥鎖重建DB。Caffeine的配置如下Bean public CacheString, Object caffeineCache() { return Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofSeconds(30)) .recordStats() .build(); }maximumSize設置的是條目數(shù)量不是內(nèi)存大小。如果單個緩存value很大比如幾十KB的JSON10萬條對堆內(nèi)存的壓力也不小所以要根據(jù)業(yè)務數(shù)據(jù)大小調。expireAfterWrite設成30秒本地緩存主要作為Redis不可用或者重建窗口期的臨時兜底不需要緩存太久越短一致性越好。有一個容易忽略的坑本地緩存和Redis如果都緩存了同一份數(shù)據(jù)兩者過期時間不一致會導致短暫的數(shù)據(jù)不一致。比如Redis的TTL是10分鐘Caffeine的過期時間是30秒那在第31秒到第10分鐘之間Redis里可能還是新數(shù)據(jù)但Caffeine已經(jīng)過期重新從Redis拉取了新的這個沒問題。反向的情況才有問題Redis過期了但Caffeine還沒過期查詢命中本地舊數(shù)據(jù)。所以Caffeine的過期時間必須小于Redis的TTL這樣它最多只能讀到比Redis稍舊的數(shù)據(jù)而Redis永遠提供更新的數(shù)據(jù)。我們在配置中心里加了注釋禁止Caffeine過期時間大于Redis TTL防止后人改錯。5. 封裝實踐工程落地與參數(shù)調優(yōu)前面講了方案和核心邏輯這一章說落地工程時踩到的具體坑和參數(shù)調優(yōu)經(jīng)驗。這一章對于一個真正要上線這套方案的人來說是關鍵參考。5.1 工程結構與依賴我們用的是Spring Boot項目緩存模塊按獨立包維護目錄結構大概是這樣com.example.cache ├── CacheService.java // 門面類業(yè)務方唯一入口 ├── BloomFilterManager.java // 布隆過濾器管理 ├── HotKeyManager.java // 熱點key識別與續(xù)期 ├── CacheWrapper.java // 邏輯過期包裝類 ├── CacheProperties.java // 配置屬性綁定 └── config ├── RedissonConfig.java ├── CaffeineConfig.java └── RedisTemplateConfig.javaMaven依賴核心是這幾個dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.23.5/version /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId version3.1.8/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependencyRedisson的spring-boot-starter會自動裝配RedissonClient省去手動建連接池的麻煩也天然支持看門狗。Caffeine是純JVM內(nèi)存緩存沒有額外依賴。5.2 RedisTemplate序列化配置的坑緩存工具能不能正常工作序列化方式影響很大。Spring Boot默認的RedisTemplate用的是JdkSerializationRedisSerializer序列化后的key會帶一串\xac\xed\x00\x05t\x00...的前綴value是二進制格式可讀性差而且有反序列化性能損耗。我們統(tǒng)一改成StringRedisSerializer做key序列化value用GenericJackson2JsonRedisSerializer做JSON序列化。這樣Redis里的key是明文用redis-cli排查問題的時候能直接看懂。代碼配置Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer keySerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer valueSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(keySerializer); template.setHashKeySerializer(keySerializer); template.setValueSerializer(valueSerializer); template.setHashValueSerializer(valueSerializer); template.afterPropertiesSet(); return template; }還有一個細節(jié)RedisTemplate在存儲NULL_PLACEHOLDER這類空值標記時GenericJackson2JsonRedisSerializer反序列化時如果泛型信息丟失可能解不回來。這會導致空值緩存的判斷邏輯失效。我們的做法是空值標記用固定字符串常量__NULL__查詢時先判斷字符串值是否等于這個常量再決定是否返回null。這個判斷在工具內(nèi)部做業(yè)務方完全無感。5.3 布隆過濾器參數(shù)調優(yōu)與初始化時機布隆過濾器的參數(shù)只能在初始化時定一次所以預估數(shù)據(jù)量很關鍵。預估少了數(shù)據(jù)量逼近容量上界后誤判率會迅速劣化預估多了位數(shù)組占用內(nèi)存偏大但也能接受。建議按業(yè)務未來一年的增長量來估比如當前用戶300萬年增長30%直接按500萬估留出余量。誤判率p取1%是比較平衡的低于0.1%時內(nèi)存占用會顯著上升收益卻不明顯。我用表格列幾個常用檔位供參考預期數(shù)據(jù)量n誤判率p位數(shù)組大小m內(nèi)存占用哈希函數(shù)個數(shù)k100萬1%958萬bit約1.14MB71000萬1%9585萬bit約11.4MB71000萬0.1%1438萬bit約17.1MB101億1%9.58億bit約114MB7初始化時機也很關鍵。我們經(jīng)歷過一次發(fā)布時忘記觸發(fā)初始化布隆過濾器空置所有查詢?nèi)逥B重建好在當時流量不大。后來把初始化放到ApplicationRunner里應用啟動完成后強行跑一次加載任務加載期間如果檢測到過濾器是空的就返回一個開關標記工具層可以直接放行因為過濾器不可用時攔截會誤傷所有請求降級為不攔截更安全并打印嚴重告警。這個開關邏輯很重要過濾器不可用時寧可退回到裸查詢也不能把合法請求全攔截了。5.4 熱點key識別與動態(tài)續(xù)期擊穿治理依賴鎖但如果我們不知道哪些key是熱點就只能對所有miss的key都加鎖。這有點浪費因為絕大多數(shù)key的并發(fā)度很低鎖的開銷雖然小但不是零。我們對熱點key做識別命中熱點的才走加權保護邏輯。熱點識別最簡單的方案是訪問計數(shù)。用一個本地ConcurrentHashMap維護每個key最近一分鐘的訪問次數(shù)或者直接用Redis的ZSet結構做滑動窗口計數(shù)。本地計數(shù)的優(yōu)勢是零額外網(wǎng)絡開銷劣勢是集群多節(jié)點時各自統(tǒng)計閾值要按單節(jié)點估算Redis ZSet的優(yōu)勢是全局統(tǒng)計準確劣勢是多了一次Redis網(wǎng)絡調用。我們用的折中方案是本地計數(shù)每10秒將計數(shù)結果批量上報到Redis工具層根據(jù)上報結果更新熱點名單。熱點名單維護在HotKeyManager中核心數(shù)據(jù)結構就是一個Set加上過期時間。當某個key在1分鐘內(nèi)被訪問超過1000次閾值可配置就把這個key加入熱點名單并對這個key做兩件事一是把物理過期時間改長禁用Redis原生TTL改用邏輯過期時間二是啟動一個后臺線程定時刷新它的緩存值。這樣熱點key幾乎不會真正過期擊穿場景被前置消除互斥鎖只作為邏輯過期后的兜底手段。后臺刷新任務的頻率要控制好。刷新太頻繁DB壓力大刷新太慢數(shù)據(jù)實時性變差。我們對不同類型的數(shù)據(jù)配置了不同的刷新間隔價格、庫存這類實時性要求高的30秒刷新一次商品描述、標題這類允許滯后的5分鐘刷新一次。這里注意刷新任務要均勻錯峰不要整點一起跑否則容易造成對DB的周期沖擊。6. 常見問題與排查技巧實錄這一章記錄的是我們上線這套封裝工具后遇到過的真實故障和排查過程每一條都是花時間踩出來的拿出來分享希望幫大家避坑。6.1 布隆過濾器“誤傷”合法請求布隆過濾器出現(xiàn)過一次嚴重誤傷大促新增了一批商品但增量寫入的邏輯漏了導致部分新商品ID在過濾器里完全不存在所有查詢都被攔成null前端頁面顯示“商品不存在”客服被問爆。排查時先看日志發(fā)現(xiàn)這些ID全部走到“bloom miss”分支然后檢查增量寫入代碼發(fā)現(xiàn)商品創(chuàng)建成功了但緩存模塊的一個事件監(jiān)聽器因為消息隊列積壓被丟棄導致add操作沒執(zhí)行。教訓有兩點一是增量寫入必須做成同步失敗重試業(yè)務寫成功后立刻同步調用過濾器的add方法不依賴異步鏈路二是啟動時和每天凌晨加一個全量校準任務把DB全量ID與過濾器對比發(fā)現(xiàn)缺失的批量補上防止漏寫導致長期帶病運行。6.2 鎖內(nèi)慢SQL導致線程堆積有次壓測發(fā)現(xiàn)熱點key的P99飆到2秒排查發(fā)現(xiàn)鎖內(nèi)查DB的SQL是一個帶子查詢的復雜語句大促數(shù)據(jù)量上來后執(zhí)行要400毫秒。雖然是互斥的只有少數(shù)線程在查但所有請求都在等鎖外的自旋重試而重試3次都拿不到緩存只能降級再去查DB相當于鎖根本保護了DB一次但等待期間的降級請求又把DB打了一次。優(yōu)化方案是拆SQL把復雜的子查詢拆成兩個簡單查詢分別緩存中間結果熱點key的緩存值只依賴第一個結果第二個結果用來做補充展示。拆完以后鎖內(nèi)耗時降到50毫秒以內(nèi)P99回到正常區(qū)間。這件事提醒我互斥鎖只能控制并發(fā)不能掩蓋DB性能差鎖內(nèi)查詢耗時是擊穿治理的生命線必須先解決。6.3 邏輯過期導致緩存更新遲遲不生效我們上線邏輯過期方案后測試同學反饋手動在后臺改了商品標題前端頁面5分鐘還不刷新。定位發(fā)現(xiàn)邏輯過期時間被設置成了10分鐘但后臺刷新任務每5分鐘才檢查一次有一個檢查窗口正好落在過期前導致數(shù)據(jù)白白等待5分鐘。后來把邏輯過期時間設定為刷新頻率的兩倍以上保證任意時刻都有過期檢查的機會。實際配置是刷新間隔5分鐘邏輯過期時間設為12分鐘這樣即便錯過一次檢查下一次也會在6分鐘內(nèi)觸發(fā)更新。6.4 空值緩存與布隆過濾器組合時的TTL不一致同時啟用空值緩存和布隆過濾器時出現(xiàn)過一次短期臟數(shù)據(jù)某個不存在ID在布隆過濾器里誤判為可能存在誤判率只有1%但架不住每天幾億次查詢于是走了緩存查詢鏈路緩存里存的空值TTL是90秒結果布隆過濾器本身的判斷是永久的導致這個ID的查詢在過濾器生命周期內(nèi)永遠在緩存里命中空值。解決方案是布隆過濾器判斷存在后緩存空值命中時也做二次校驗如果DB返回了數(shù)據(jù)說明可能是過濾器誤判造成的空值緩存命中了真實數(shù)據(jù)此時強制把空值替換為真實值。簡單說空值緩存不應該被當成“真實狀態(tài)”它只是一個臨時緩解措施一旦DB中出現(xiàn)了數(shù)據(jù)必須以DB為準。6.5 多節(jié)點本地緩存的一致性問題Caffeine本地緩存上線后多節(jié)點的數(shù)據(jù)一致性出現(xiàn)過困惑同一時刻不同節(jié)點返回的數(shù)據(jù)可能不相同因為每個節(jié)點緩存刷新的時間點是漂移的。比如節(jié)點A剛更新完緩存節(jié)點B還是舊值用戶負載均衡打到不同節(jié)點就看到不同數(shù)據(jù)。這個現(xiàn)象對大多數(shù)讀多寫少的業(yè)務場景是可接受的比如商品詳情、活動頁但對強一致要求的場景不能接受。我們的處理方式是在配置里按數(shù)據(jù)維度拆分強一致數(shù)據(jù)不啟用Caffeine這一層只走Redis和鎖弱一致數(shù)據(jù)啟用Caffeine且過期時間統(tǒng)一隨機化錯峰。上線前需要和產(chǎn)品對齊“容忍多少秒的數(shù)據(jù)延遲”大部分場景30秒以內(nèi)都能接受。6.6 壓測時的一個隱藏陷阱壓測時容易忽略布隆過濾器和熱點名單的預熱。壓測腳本上來就并發(fā)打熱點此時熱點名單還沒建立所有請求走的都是基礎的鎖重試邏輯測出來的數(shù)值不代表真實上線水平。正確做法是壓測前先跑一個預熱腳本模擬真實訪問幾次讓熱點名單和本地緩存都填充起來再開始壓正式場景。另外壓測數(shù)據(jù)的數(shù)據(jù)量如果遠小于生產(chǎn)布隆過濾器的誤判率會顯得非常低壓測結果偏樂觀要意識到這個差異。7. 從這套封裝中沉淀的經(jīng)驗代碼方案講完了最后說幾個我對封裝這件事本身的看法。我自己最大的體會是封裝工具層不是把復雜度藏起來就完事了恰恰相反它把復雜度從業(yè)務代碼集中到了那么幾個類里所以這幾個類的正確性和可觀測性比什么都重要。我們給工具層加了大量日志和指標任何一個分支命中都要能追蹤到是哪一層攔的、哪個環(huán)節(jié)慢的這樣線上出了問題才不用靠猜。另外一點緩存治理沒有一勞永逸的方案。布隆過濾器對存量數(shù)據(jù)有效但增量寫入、刪除殘留都需要持續(xù)維護互斥鎖能保護瞬時沖擊但DB本身慢還是慢本地緩存能扛抖動但一致性永遠是相對的不是絕對的。這套工具箱能覆蓋大部分場景但每接入一個業(yè)務還是要回到業(yè)務本身去看它的數(shù)據(jù)屬性、一致性要求、訪問特征挑選適合的策略組合。如果你們團隊的緩存防護還處在手寫判斷的階段我的建議是先別急著照抄代碼。第一步先想清楚你們目前最痛的是穿透還是擊穿——是經(jīng)常被攻擊者刷無效請求還是大促時熱點key過期導致DB抖動。把這個核心矛盾定下來再決定三層防護里優(yōu)先落地哪層。大多數(shù)團隊第一步做鎖就夠了穿透是高危時再上布隆過濾器。工具封裝是手段讓線上服務在極端流量下還能穩(wěn)住才是我們最終要的東西。