緩存穿透這個問題很多團隊是在線上事故中第一次認識它的。某個周二的晚上監控大屏突然飄紅數據庫連接池被耗盡接口平均響應時間從 30ms 漲到 5 秒用戶端看到的頁面全是超時和錯誤。開發同學登錄服務器看日志發現同一個商品 ID 在短時間內被請求了上萬次而這個商品 ID 在數據庫里根本不存在。這是一次非常典型的緩存穿透事故。請求繞過緩存直接打到數據庫把一個 MySQL 實例活生生打掛了。更麻煩的是這種請求通常是惡意腳本在循環遍歷你殺了一個 ID他就換下一個幾乎無法通過人工封號解決。這篇文章就把緩存穿透這件事講透它到底是什么為什么這么難防以及緩存空值、布隆過濾器、接口限流這三道防線分別怎么落地。最后我會給出一套可運行的 Spring Boot 示例代碼方便你直接在自己的項目中對照實踐把數據庫從“裸奔”狀態下救回來。1. 緩存穿透到底“穿透”了什么一次夜間事故的復盤先復盤一下文章開頭說的那次事故。你的系統正常情況下是這樣的用戶查詢商品詳情首先查 Redis如果 Redis 里面有數據直接返回根本不碰數據庫。只有當 Redis 里沒有這個 key 時才會去查 MySQL查完之后再把數據回填到 Redis。正常請求用戶 - Redis命中 - 返回 緩存未命中用戶 - Redis未命中 - MySQL - 回填 Redis - 返回這個流程看起來沒有問題但里面藏著一個漏洞當查詢的 key 在 Redis 和 MySQL 中都不存在時緩存層就沒有任何作用了。攻擊者構造一個不存在的商品 ID比如 99999999。你的程序查 Redis發現沒有這個 key于是去查 MySQLMySQL 也查不到程序返回“商品不存在”同時也不會寫入緩存。下一次請求同樣的 ID程序再查 Redis還是沒有再去查 MySQL。每一次請求都穿越了緩存直達數據庫。攻擊者不需要費多大力氣只要用腳本循環遍歷一批不存在的 ID就能把你數據庫的 QPS 打滿。這就是“緩存穿透”這個名稱的由來流量繞過了緩存這層盾牌直接穿透到了數據庫身上。真正容易踩坑的地方是很多人以為緩存穿透是 Redis 配置問題或者緩存中間件的問題其實完全不是。緩存組件本身工作正常它只是沒有能力擋住“查不到數據”的請求因為這類請求天然無法被緩存命中。這是一個分布式系統防御設計的問題而不是緩存組件故障的問題。從本質上看緩存穿透之所以危險是因為它把數據庫暴露在了無差別流量的沖擊之下。數據庫的性能是有限的它的連接數、線程數、磁盤 IO 都有上限而攻擊者制造無效請求的成本幾乎為零。你越依賴數據庫數據庫就越脆弱你越依賴緩存緩存就越容易被“查無此 key”的流量繞過。要解決這個問題核心邏輯有三條路第一讓緩存能夠處理“查到空結果”的情況第二在查詢緩存之前用更廉價的數據結構判斷這個 key 到底存不存在第三在接口層限制可疑流量的訪問頻率。后面三個章節會逐一展開。2. 緩存穿透、緩存擊穿、緩存雪崩三個概念別再傻傻分不清在講方案之前必須先厘清三個經常一起出現的概念。很多人在面試里能背出定義一到排查問題時就把它們混為一談最終導致方案用錯。概念關鍵特征觸發條件典型解決思路緩存穿透查詢的數據在緩存和數據庫中都不存在惡意請求遍歷不存在的 ID緩存空值、布隆過濾器、參數校驗、限流緩存擊穿某個熱點 key 過期瞬間大量請求同時打到數據庫熱點數據過期且并發極高互斥鎖、邏輯過期、熱點數據預熱緩存雪崩大量 key 同時過期導致數據庫瞬間壓力暴增大批 key 設置了相同的過期時間過期時間加隨機值、多級緩存、熔斷降級三者的區別用場景來理解最直觀。緩存穿透是“打了一個不存在的靶子”靶子本來就不在所以緩存永遠擋不住。緩存擊穿是“打一個很熱的靶子但靶子剛好被撤了下來”也就是熱點 key 在過期的一瞬間緩存失效并發請求全部落到數據庫。緩存雪崩則是“所有靶子一起被撤下來”大量 key 在同一時間過期數據庫承受不了瞬間的請求洪峰。從解決方向上看三者完全不同。緩存穿透的核心是“如何低成本地判斷 key 不存在”緩存擊穿的核心是“如何保證熱點 key 過期時只有一個請求去重建緩存”緩存雪崩的核心是“如何避免過期時間過于集中”。本文只解決緩存穿透但你需要知道它的邊界。一個完整的緩存防護體系往往需要同時考慮穿透、擊穿和雪崩少了任何一個環節數據庫都可能被找到新的突破口。3. 最容易被打穿的業務場景哪些項目風險最高并非所有項目都會遇到緩存穿透。它通常需要滿足兩個條件一是業務中存在“查詢不到數據”的合法場景二是接口接收外部傳入的 ID 或者編碼。如果你的系統滿足這兩個條件那么緩存穿透就只是一個時間問題。以下四類場景是最常見的重災區。商品詳情類接口。商品 ID 是用戶可猜測的而且商品可能存在下架、刪除等狀態。攻擊者只需要從 1 開始遞增遍歷就能制造大量不存在的 ID。電商大促期間這類接口往往沒有嚴格限流一旦被打穿數據庫會立刻成為瓶頸。訂單查詢類接口。訂單號通常是業務號可預測性較強。很多系統在查詢訂單時先查緩存再查數據庫最后返回“訂單不存在”。但一個不存在的訂單號依然會觸發完整的數據庫查詢鏈路。用戶 Token 或賬號校驗。這類接口使用頻繁流量大而且外部攻擊者可以隨機生成無效 Token 來試探。每一次無效 Token 校驗都會穿透緩存直接把壓力施加到用戶表或登錄日志表上。短鏈解析和邀請碼核銷類業務。短鏈碼、邀請碼的字符空間有限攻擊者可以批量遍歷。如果數據庫中沒有對應記錄緩存又無法命中請求就會全部打到數據庫。這些場景有一個共同特點接口對外開放參數可預測業務存在“查不到是正常情況”的語義。只要你的系統滿足這三個條件就必須主動考慮緩存穿透防護而不是等監控報警之后再去救火。另外還要警惕一種容易忽略的情況業務邏輯里“軟刪除”的數據。比如商品狀態被置為 1已刪除查詢主流程可能不會返回但數據庫里確實存在這條記錄。如果查詢條件只過濾狀態位不帶主鍵白名單這類數據也會表現出“查不到”的特征從而成為穿透流量的目標。4. 方案一緩存空值給不存在的 key 也安排一個座位緩存穿透最直接的原因是“查不到的數據無緩存可命”。那么思路自然就來了既然查不到那我把“查不到”這個結果也緩存起來問題不就解決了嗎這就是緩存空值方案。4.1 原理與實現思路當數據庫查詢結果為空時不要直接返回而是把一個特殊標記寫入緩存并設置一個較短的過期時間。這樣下一次同樣的 key 過來緩存能命中這個空值標記接口直接返回“不存在”不再查詢數據庫。關鍵代碼如下// 文件路徑src/main/java/com/example/demo/service/ProductService.java Service public class ProductService { private static final String PRODUCT_CACHE_PREFIX product:detail:; private static final String EMPTY_MARK EMPTY; Autowired private StringRedisTemplate redisTemplate; Autowired private JdbcTemplate jdbcTemplate; private final ObjectMapper objectMapper new ObjectMapper(); public Product getProductById(Long id) { // 第 1 步參數校驗后面會細講 if (id null || id 0) { return null; } String cacheKey PRODUCT_CACHE_PREFIX id; // 第 2 步查緩存 String cachedValue redisTemplate.opsForValue().get(cacheKey); if (cachedValue ! null) { if (EMPTY_MARK.equals(cachedValue)) { return null; } try { return objectMapper.readValue(cachedValue, Product.class); } catch (JsonProcessingException e) { // 緩存數據損壞時按穿透處理回源數據庫 redisTemplate.delete(cacheKey); } } // 第 3 步查數據庫 Product product queryFromDb(id); // 第 4 步回填緩存 if (product null) { // 空值也緩存過期時間短一點并加隨機抖動防止集中過期 int emptyCacheSeconds 180 new Random().nextInt(120); redisTemplate.opsForValue().set( cacheKey, EMPTY_MARK, emptyCacheSeconds, TimeUnit.SECONDS ); return null; } // 真實數據緩存 30 分鐘同時加隨機抖動 int realCacheSeconds 1800 new Random().nextInt(300); try { String json objectMapper.writeValueAsString(product); redisTemplate.opsForValue().set( cacheKey, json, realCacheSeconds, TimeUnit.SECONDS ); } catch (JsonProcessingException e) { throw new RuntimeException(商品序列化失敗, e); } return product; } private Product queryFromDb(Long id) { try { return jdbcTemplate.queryForObject( SELECT id, name, price FROM product WHERE id ?, new BeanPropertyRowMapper(Product.class), id ); } catch (EmptyResultDataAccessException e) { // 查詢結果為空返回 null 給上層做空值緩存 return null; } } }4.2 這里真正容易踩坑的地方緩存空值方案實現簡單效果立竿見影但它有幾個容易被忽略的坑。第一個坑是空值 key 占內存。惡意流量遍歷 100 萬個不存在的 ID就會在 Redis 中產生 100 萬個空值 key。這些 key 雖然設置了過期時間但在過期之前依然占用內存。如果業務量大Redis 內存會快速上漲。解決辦法是給空值 key 設置統一前綴比如null:后續可以寫定時任務批量清理或者降低空值緩存時間。第二個坑是空值緩存時間不宜過長。如果你把不存在的商品 ID 緩存 30 分鐘而商品剛好在 10 分鐘后被重新上架用戶在 20 分鐘內仍然查不到這個商品。這會直接導致數據一致性問題而且很難排查。因此空值緩存時間建議控制在 2 到 5 分鐘加上隨機抖動既起到防穿透作用又能接受短時間內的數據延遲。第三個坑是要區分“緩存空值”和“緩存數據異常”。當緩存中讀取到EMPTY_MARK時返回空結果當讀到非空字符串但 JSON 解析失敗時說明緩存數據已經損壞應該刪除緩存并回源數據庫而不是直接返回“不存在”。這段邏輯在示例代碼中已經體現出來很多初學者會漏掉。緩存空值適合的業務形態是數據量不大、攻擊流量有限、希望快速落地解決。它是防穿透方案的“下限”幾乎每個項目都應該先做這一步。5. 方案二布隆過濾器把非法 key 攔截在查詢之前緩存空值方案是事后攔截請求先打到緩存發現沒命中然后緩存空值把后續請求擋住。但空值 key 本身還會短暫占內存而且如果攻擊流量在空值過期后再次發起依然會穿透。布隆過濾器則是一種前置攔截方案在查緩存之前先判斷 key 到底存不存在如果過濾器認為不存在直接返回連 Redis 都不查。5.1 布隆過濾器是怎么工作的布隆過濾器是一個非常節省內存的概率性數據結構。它的核心邏輯是把所有合法 key 通過多個哈希函數映射到一個很長的位數組上在位數組中把對應位置置為 1。查詢時同樣計算多個哈希值如果所有對應位置都是 1則認為 key “可能存在”只要有任何一個位置為 0則可以確定 key “一定不存在”。簡單理解它是一個“大概率在名單里”的檢查員。如果它說“不在”那就一定不在如果它說“在”只是大概率在也有小概率誤判。對于緩存穿透場景這個特性非常合適。我們只關心“這個 ID 到底是不是合法商品 ID”如果一個 ID 被過濾器判定為不存在就直接返回“商品不存在”根本不用繼續查緩存和數據庫。即使誤判了一個不存在的 ID 為可能存在最壞的結果也就是多查一次數據庫不會返回錯誤結果。5.2 使用 Guava 實現布隆過濾器在 Java 項目中最常用的布隆過濾器實現是 Google Guava。以下代碼示例展示了如何在應用啟動時加載所有商品 ID并在查詢時進行過濾判斷// 文件路徑src/main/java/com/example/demo/filter/ProductBloomFilter.java Component public class ProductBloomFilter { // 預計要放入過濾器的元素數量 private static final int EXPECTED_INSERTIONS 100000; // 誤判率越低越占內存這里設置為 1% private static final double FPP 0.01; private final BloomFilterLong bloomFilter BloomFilter.create(Funnels.longFunnel(), EXPECTED_INSERTIONS, FPP); Autowired private JdbcTemplate jdbcTemplate; PostConstruct public void init() { ListLong ids jdbcTemplate.queryForList( SELECT id FROM product, Long.class ); ids.forEach(bloomFilter::put); } /** * 判斷商品 ID 是否可能存在。 * false 表示一定不存在true 表示可能存在。 */ public boolean mightContain(Long id) { return bloomFilter.mightContain(id); } }接入查詢鏈路時只需要在ProductService.getProductById方法的最前面加一段判斷Autowired private ProductBloomFilter productBloomFilter; public Product getProductById(Long id) { if (id null || id 0) { return null; } // 布隆過濾器前置判斷不存在直接返回 if (!productBloomFilter.mightContain(id)) { return null; } // 后續查緩存、查數據庫的邏輯保持不變 }5.3 布隆過濾器的局限與更新策略布隆過濾器也不是銀彈使用它之前必須想清楚數據更新策略。最大的問題在于新增數據的同步。布隆過濾器在應用啟動時一次性加載所有商品 ID但業務是動態的每天都會有新商品上架。如果新增商品后沒有把新 ID 放入過濾器這個新商品會被誤判為“不存在”用戶永遠查不到。解決做法有三種增量更新在商品創建的 Service 方法中同步調用bloomFilter.put(id)。實現簡單但需要保證業務代碼中所有創建入口都不遺漏一旦遺漏就會產生線上問題。定時全量重建每天凌晨從數據庫重新加載全部商品 ID構建新的過濾器。需要解決新舊過濾器切換的問題可以用雙緩沖即維護兩份過濾器重建完成后切換引用。混合策略增量更新保證實時性定時重建兜底防止增量遺漏積累。另一個局限性是過濾器啟動加載大 key 集合時耗時較長。如果平臺有上億商品數據一次性加載可能耗時幾分鐘。可以考慮只用熱點或高權重商品的 ID 構建過濾器或使用 Redis 的 BitMap 實現分布式布隆過濾器避免單應用內存受限。布隆過濾器適用的業務形態是數據量大、相對穩定、存在可預知的合法 key 全集并且希望把無效流量在 Redis 之前就攔截掉。在中小項目里它不是第一優先級但在高并發 C 端系統中它通常是防穿透體系里最前面的一道閘門。6. 方案三接口層防護流量層面的最后一道保險緩存空值和布隆過濾器解決的是“數據層面”的穿透問題但還有一個維度需要防守如果攻擊者流量足夠大即使每個 key 只查一次數據庫也能把你的數據庫打掛。這時候光靠緩存層的方案就不夠了還需要在接口層和流量層做防護。6.1 參數校驗是第一道口子很多緩存穿透事故的根源是接口沒有對入參做基本校驗任何數字都可以進入查詢鏈路。先看你的接口是不是也存在這種情況。一個商品 ID 不可能小于等于 0不可能超過某個合理的業務范圍也通常不會是負數。如果這些非法參數都能直接進入 Service 層說明你的參數校驗還不到位。在 Spring Boot 項目中可以引入spring-boot-starter-validation或在 Controller 層手動校驗。GetMapping(/{id}) public ResultProduct getProduct(PathVariable Long id) { if (id null || id 0 || id 999999999L) { return Result.error(無效的商品 ID); } return productService.getProductById(id); }注意參數校驗只是過濾掉“明顯非法”的請求并不能防御“ID 本身合法但商品不存在”的穿透流量。所以參數校驗是地基但不能只靠它。6.2 基于 key 維度的限流把惡意請求擋在業務邏輯之外限流是接口層保護數據庫的關鍵手段。我們的目標是對同一個 key 的訪問頻率進行限制一旦超過閾值直接拒絕請求。在實踐中更專業的做法是基于 Redis 的滑動窗口或者令牌桶實現分布式限流。這里先給一個本地內存版的時間窗口限流示例雖然只適用于單機演示但限流思路和代碼結構完全一樣// 文件路徑src/main/java/com/example/demo/limit/KeyRateLimiter.java Component public class KeyRateLimiter { // key - 訪問時間戳隊列 private final ConcurrentHashMapString, DequeLong visitWindow new ConcurrentHashMap(); // 每個 key 在 60 秒內最多允許訪問 50 次 private static final int LIMIT 50; private static final long WINDOW_MILLIS 60_000L; /** * 檢查當前 key 是否超過限流閾值。 */ public boolean isOverLimit(String key) { long now System.currentTimeMillis(); DequeLong deque visitWindow.computeIfAbsent(key, k - new ArrayDeque()); synchronized (deque) { // 清理窗口之外的時間記錄 while (!deque.isEmpty() now - deque.peekFirst() WINDOW_MILLIS) { deque.pollFirst(); } if (deque.size() LIMIT) { return true; } deque.addLast(now); } return false; } }然后在查詢商品前先判斷當前 key 是否已經被限流Autowired private KeyRateLimiter keyRateLimiter; public Product getProductById(Long id) { String rateLimitKey rate:product: id; if (keyRateLimiter.isOverLimit(rateLimitKey)) { throw new BizException(請求過于頻繁請稍后重試); } // 其余查詢邏輯不變 }這個本地實現有幾個明顯問題第一它只在單機內存中生效多實例部署時必須換成 Redis Lua 實現第二它把同一個 key 的正常并發請求也限住了比如秒殺活動中有 1000 人同時搶購同一個商品第一個請求到達后后面 949 個請求都會被誤傷。因此限流閾值必須根據業務壓測結果來決定并且針對搶購等熱點場景要單獨設計。6.3 限流解決的是“惡意流量”問題而不是“數據不存在”問題需要說明的是接口限流并不能在數據結構層面解決緩存穿透它的作用是當緩存層和布隆過濾器都被繞過時限制攻擊速率避免數據庫瞬間被打掛。一套完整的接口防護還應該包括IP 維度的限流、用戶維度的限流、短期失敗次數的黑名單機制以及第一時間對異常流量來源進行告警。這些能力通常由網關層承擔但如果你沒有網關這些邏輯就必須寫在應用層。接口層防護適用任何對外提供服務的系統。它不一定能完全消除穿透流量但它能保證你的數據庫在最壞情況下依然有喘息的空間。7. 三種方案選型對比別把全部武器一次堆上去講了三種方案你可能會糾結到底該用哪一種。這里做一個直接了當的選型建議。方案實現成本對內存的占用防穿透效果誤傷/數據風險適用階段緩存空值低較高空值 key 也會占內存好能擋住重復無效請求低但存在短暫的數據一致性問題中小項目、快速上線兜底布隆過濾器中低位數組非常省內存好能在緩存之前攔截大部分無效 key如果新增數據不同步會“誤殺”真實數據數據量大、key 集合穩定的系統接口限流與參數校驗中高低輔助性兜底不能根除穿透閾值設置不當會誤傷正常用戶公網接口、惡意攻擊場景從實踐角度看我建議按業務體量分三檔來選第一檔剛起步的項目或者內部系統直接做參數校驗 緩存空值。不要引入布隆過濾器因為動態數據同步的成本比收益還高。緩存空值能擋住 90% 的重復穿透流量足夠應對常規風險。第二檔有一定流量的 C 端系統參數校驗 緩存空值 接口限流。重點是限流閾值要經過壓測不能拍腦袋。這個組合能應對大多數惡意遍歷場景。第三檔大規模高并發平臺在前兩檔基礎上增加布隆過濾器并配套完善的數據同步機制。同時把限流下沉到網關層應用層只保留業務校驗和最后的保護邏輯。這里有一個常見的決策誤區很多人喜歡一次性把三種方案都堆上去覺得越多的方案越安全。但實際上每多一個組件就多一份維護成本和一個故障點。布隆過濾器的誤殺風險、限流的誤傷風險都比緩存空值更隱蔽如果團隊沒有足夠的監控和快速回滾能力不建議在項目初期就全量上線。記住一句話緩存空值是兜底布隆過濾器是攔截限流是保命。三個方案不是互相替代的關系而是按風險等級逐層設防的關系。8. 完整實戰Spring Boot 集成緩存空值與接口限流前面講完了原理和選型這一節提供一個可以直接運行的 Spring Boot 示例工程。示例會組合“參數校驗 緩存空值 本地 key 維度限流”三套邏輯并附加布隆過濾器的可選接入方式方便你對照練習。8.1 環境準備與項目結構本文示例以 Spring Boot 3.2.x 為基礎使用 JDK 17操作系統不限。Redis 建議使用 5.0 以上版本MySQL 使用 5.7 或 8.0 均可。如果你本機沒有 MySQL也可以用內存數據庫 H2 代替SQL 部分需要做少量調整。!-- 文件路徑pom.xml -- ?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version relativePath/ /parent groupIdcom.example/groupId artifactIdcache-penetration-demo/artifactId version1.0.0/version namecache-penetration-demo/name description緩存穿透防護示例/description properties java.version17/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdcom.google.guava/groupId artifactIdguava/artifactId version32.1.3-jre/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies /project# 文件路徑src/main/resources/application.yml server: port: 8080 spring: application: name: cache-penetration-demo redis: host: 127.0.0.1 port: 6379 timeout: 3000ms datasource: url: jdbc:mysql://127.0.0.1:3306/demo_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver示例工程結構如下src/main/java/com/example/demo ├── CachePenetrationDemoApplication.java ├── controller │ └── ProductController.java ├── service │ └── ProductService.java ├── entity │ └── Product.java ├── limit │ └── KeyRateLimiter.java └── common └── Result.java8.2 核心代碼實現產品實體類// 文件路徑src/main/java/com/example/demo/entity/Product.java public class Product { private Long id; private String name; private BigDecimal price; public Long getId() { return id; } public void setId(Long id) { this.id id; } public String getName() { return name; } public void setName(String name) { this.name name; } public BigDecimal getPrice() { return price; } public void setPrice(BigDecimal price) { this.price price; } }統一返回體// 文件路徑src/main/java/com/example/demo/common/Result.java public class ResultT { private int code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } // getter / setter 省略建議使用 lombok 簡化 }限流器就是前面提到的時間窗口本地版// 文件路徑src/main/java/com/example/demo/limit/KeyRateLimiter.java Component public class KeyRateLimiter { private final ConcurrentHashMapString, DequeLong visitWindow new ConcurrentHashMap(); private static final int LIMIT 50; private static final long WINDOW_MILLIS 60_000L; public boolean isOverLimit(String key) { long now System.currentTimeMillis(); DequeLong deque visitWindow.computeIfAbsent(key, k - new ArrayDeque()); synchronized (deque) { while (!deque.isEmpty() now - deque.peekFirst() WINDOW_MILLIS) { deque.pollFirst(); } if (deque.size() LIMIT) { return true; } deque.addLast(now); } return false; } }產品 Service組合了參數校驗、緩存空值和限流邏輯// 文件路徑src/main/java/com/example/demo/service/ProductService.java Service public class ProductService { private static final String PRODUCT_CACHE_PREFIX product:detail:; private static final String EMPTY_MARK EMPTY; Autowired private StringRedisTemplate redisTemplate; Autowired private JdbcTemplate jdbcTemplate; Autowired private KeyRateLimiter keyRateLimiter; private final ObjectMapper objectMapper new ObjectMapper(); public Product getProductById(Long id) { if (id null || id 0) { return null; } String cacheKey PRODUCT_CACHE_PREFIX id; String rateLimitKey rate:product: id; if (keyRateLimiter.isOverLimit(rateLimitKey)) { throw new RuntimeException(請求過于頻繁請稍后重試); } String cachedValue redisTemplate.opsForValue().get(cacheKey); if (cachedValue ! null) { if (EMPTY_MARK.equals(cachedValue)) { return null; } try { return objectMapper.readValue(cachedValue, Product.class); } catch (JsonProcessingException e) { redisTemplate.delete(cacheKey); } } Product product queryFromDb(id); if (product null) { int emptyCacheSeconds 180 new Random().nextInt(120); redisTemplate.opsForValue().set(cacheKey, EMPTY_MARK, emptyCacheSeconds, TimeUnit.SECONDS); return null; } int realCacheSeconds 1800 new Random().nextInt(300); try { String json objectMapper.writeValueAsString(product); redisTemplate.opsForValue().set(cacheKey, json, realCacheSeconds, TimeUnit.SECONDS); } catch (JsonProcessingException e) { throw new RuntimeException(商品序列化失敗, e); } return product; } private Product queryFromDb(Long id) { try { return jdbcTemplate.queryForObject( SELECT id, name, price FROM product WHERE id ?, new BeanPropertyRowMapper(Product.class), id ); } catch (EmptyResultDataAccessException e) { return null; } } }Controller// 文件路徑src/main/java/com/example/demo/controller/ProductController.java RestController RequestMapping(/product) public class ProductController { Autowired private ProductService productService; GetMapping(/{id}) public ResultProduct getProduct(PathVariable Long id) { if (id null || id 0 || id 999999999L) { return Result.error(無效的商品 ID); } try { Product product productService.getProductById(id); if (product null) { return Result.error(商品不存在); } return Result.success(product); } catch (RuntimeException e) { return Result.error(e.getMessage()); } } }8.3 可選的布隆過濾器接入方式如果你在真實項目中決定使用布隆過濾器可以在上述工程基礎上增加ProductBloomFilter類然后在ProductService.getProductById的最前面增加一次判斷。注意只有在你能保證商品 ID 增量同步到過濾器時才建議開啟否則不要貿然接進去。// 文件路徑src/main/java/com/example/demo/filter/ProductBloomFilter.java Component public class ProductBloomFilter { private static final int EXPECTED_INSERTIONS 100000; private static final double FPP 0.01; private final BloomFilterLong bloomFilter BloomFilter.create(Funnels.longFunnel(), EXPECTED_INSERTIONS, FPP); Autowired private JdbcTemplate jdbcTemplate; PostConstruct public void init() { ListLong ids jdbcTemplate.queryForList( SELECT id FROM product, Long.class ); ids.forEach(bloomFilter::put); } public boolean mightContain(Long id) { return bloomFilter.mightContain(id); } }接入查詢服務Autowired private ProductBloomFilter productBloomFilter; public Product getProductById(Long id) { if (id null || id 0) { return null; } if (!productBloomFilter.mightContain(id)) { return null; } // 其余邏輯不變 }啟動類// 文件路徑src/main/java/com/example/demo/CachePenetrationDemoApplication.java SpringBootApplication public class CachePenetrationDemoApplication { public static void main(String[] args) { SpringApplication.run(CachePenetrationDemoApplication.class, args); } }8.4 初始化數據表執行下面的 SQL 創建商品表并插入兩條測試數據CREATE TABLE product ( id BIGINT PRIMARY KEY, name VARCHAR(64) NOT NULL, price DECIMAL(10, 2) NOT NULL ); INSERT INTO product (id, name, price) VALUES (1, iPhone 15 Pro, 8999.00), (2, MacBook Pro 14, 14999.00);9. 運行結果與效果驗證啟動 Redis 和 MySQL 后在項目根目錄執行mvn spring-boot:run應用啟動成功后用 curl 驗證效果。第一次查詢存在的商品 IDcurl http://localhost:8080/product/1預期返回{code:200,message:success,data:{id:1,name:iPhone 15 Pro,price:8999.00}}連續查詢第二次Redis 中已經有緩存觀察日志會發現不會再次查詢數據庫。查詢不存在的商品 IDcurl http://localhost:8080/product/999第一次會查數據庫并寫入空值緩存。預期返回{code:500,message:商品不存在,data:null}然后再次請求相同的 ID預期返回結果相同但數據庫不會收到新的查詢。可以到 Redis 中確認空值 key 已寫入redis-cli 127.0.0.1:6379 GET product:detail:999 EMPTY 127.0.0.1:6379 TTL product:detail:999 (integer) 172驗證限流在短時間內用同一個不存在的 ID 連續請求超過 50 次預期會看到接口返回“請求過于頻繁請稍后重試”。如果需要模擬真實壓測效果可以用ab等工具對同一個不存在的 ID 發起高頻請求同時觀察數據庫的查詢日志或者慢日志。你會發現在沒有空值緩存之前每一次請求都會落到數據庫而接入空值緩存和限流之后除了第一批請求后續請求都被 Redis 和限流邏輯攔截了。ab -n 10000 -c 100 http://localhost:8080/product/999判斷成功的標準有三個第一應用日志中 MySQL 查詢次數不再隨請求數線性增長第二Redis 中空值 key 數量保持穩定第三數據庫連接池水位和 QPS 沒有明顯波動。10. 常見問題與排查思路下面整理了緩存穿透防護落地過程中比較常見的幾類問題大家可以對照排查。問題現象可能原因排查方式解決方案Redis 內存快速上漲空值 key 過多用redis-cli --bigkeys或SCAN統計空值前綴 key 數量降低空值過期時間寫清理任務清理null:前綴 key或考慮布隆過濾器前置攔截新上架商品查詢返回“不存在”布隆過濾器沒有同步增量 ID查看商品創建方法中是否調用了put方法在創建入口同步更新過濾器或采用定時全量重建策略正常用戶請求被限流誤傷限流閾值設置過低查看限流日志和 QPS 峰值根據壓測數據調整閾值對搶購熱點單獨配置或改用令牌桶算法空值緩存過期后再次打爆數據庫空值時間太短攻擊流量持續查看 Redis 空值 key 的過期時間和 DB QPS 曲線調長空值緩存時間并加隨機抖動疊加布隆過濾器攔截并發第一次請求時數據庫瞬間沖高緩存未命中時沒有互斥重建查看 DB QPS 峰值與 Redis key 過期時間是否對應對緩存重建增加分布式鎖同一 key 只允許一個線程查 DB商品數據庫更新后緩存還是舊值緩存沒有及時失效檢查更新方法是否刪除緩存采用 Cache Aside 模式先更新數據庫再刪除緩存并做好重試機制排查時有一個基本順序先看 Redis 緩存是否生效再看空值 key 是否存在再看限流日志最后才去翻數據庫慢查詢日志。很多問題并不是第一層防線失效而是多層防線中的某一層配置出了問題逐層檢查能快速縮小范圍。11. 生產環境最佳實踐從“能防”到“防得住”方案落地之后更重要的是把防護體系變成可持續運行的生產能力。從工程實踐角度看有四個方向值得投入。第一個方向是監控指標。緩存穿透防護是否生效不能靠感覺要靠數據。建議至少監控以下指標Redis 緩存命中率、數據庫查詢 QPS、空值 key 數量、限流拒絕次數。其中空值 key 數量是一個很敏感的指標如果它在短時間內急劇增長說明要么有攻擊流量要么業務上出現了大量無效查詢需要第一時間告警。第二個方向是緩存過期時間的隨機性。無論是真實數據還是空值緩存過期時間都要加隨機抖動。如果所有 key 都在同一秒過期緩存穿透問題還沒解決就可能先引發緩存雪崩。隨機值的范圍可以參考基礎過期時間的 10% 到 30%。第三個方向是優雅降級。在極端情況下即使有緩存空值和布隆過濾器數據庫仍可能因為瞬時流量過大而瀕臨崩潰。此時需要應用層具備快速降級能力對非核心接口直接返回降級數據對核心接口啟用簡化版查詢必要時直接熔斷數據庫查詢先保住系統可用性再恢復數據一致性。第四個方向是全鏈路壓測。不要在事故發生后才驗證方案是否有效。上線前用 ab、JMeter 或 Locust 模擬高頻穿透流量觀察數據庫 QPS 和連接池水位。壓測目標不是“不報錯”而是“在攻擊流量翻倍時數據庫依然有冗余容量”。如果你發現數據庫 QPS 已經打滿說明防線層級不夠需要繼續往前加攔截。第五個方向是安全邊界。對于公網接口建議在網關層增加 IP 維度的限流和黑名單機制并記錄攻擊特征。對明顯的遍歷行為比如短時間內大量不同 ID 的 404 請求可以自動識別并加入臨時黑名單。這些機制的實現成本和運維成本不低但一旦遇到惡意攻擊它們往往是保護數據庫不被拖垮的關鍵。12. 最后要說的話緩存穿透從來都不是緩存的錯而是你的系統在數據訪問鏈路上缺少“安保意識”。如果把數據庫比作一家銀行的金庫緩存就是金庫外面的接待大廳而布隆過濾器是大門處的安檢員緩存空值是給“找不到人”的情況做的登記簿限流則是保安隊伍。每一層防線都有自己的作用少了任何一層金庫的直接暴露風險都會升高。如果你是在接手一個老項目我建議先不要急著把三種方案全部堆上去。第一步翻一翻線上日志確認是否存在大量“查無此數據”的重復請求第二步把接口參數校驗補上給每個讀接口加一個合理的邊界約束第三步實現緩存空值這是投入產出比最高的一步。等觀察一段時間確認確實存在惡意穿透流量再逐步引入布隆過濾器和分布式限流。數據庫是慢變量保護它的關鍵永遠是把流量擋在更前面的位置。希望這篇文章能幫你少踩一個洞也少熬一個夜。