緩存穿透這個問題很多團隊是在線上事故中第一次認(rèn)識它的。某個周二的晚上監(jiān)控大屏突然飄紅數(shù)據(jù)庫連接池被耗盡接口平均響應(yīng)時間從 30ms 漲到 5 秒用戶端看到的頁面全是超時和錯誤。開發(fā)同學(xué)登錄服務(wù)器看日志發(fā)現(xiàn)同一個商品 ID 在短時間內(nèi)被請求了上萬次而這個商品 ID 在數(shù)據(jù)庫里根本不存在。這是一次非常典型的緩存穿透事故。請求繞過緩存直接打到數(shù)據(jù)庫把一個 MySQL 實例活生生打掛了。更麻煩的是這種請求通常是惡意腳本在循環(huán)遍歷你殺了一個 ID他就換下一個幾乎無法通過人工封號解決。這篇文章就把緩存穿透這件事講透它到底是什么為什么這么難防以及緩存空值、布隆過濾器、接口限流這三道防線分別怎么落地。最后我會給出一套可運行的 Spring Boot 示例代碼方便你直接在自己的項目中對照實踐把數(shù)據(jù)庫從“裸奔”狀態(tài)下救回來。1. 緩存穿透到底“穿透”了什么一次夜間事故的復(fù)盤先復(fù)盤一下文章開頭說的那次事故。你的系統(tǒng)正常情況下是這樣的用戶查詢商品詳情首先查 Redis如果 Redis 里面有數(shù)據(jù)直接返回根本不碰數(shù)據(jù)庫。只有當(dāng) Redis 里沒有這個 key 時才會去查 MySQL查完之后再把數(shù)據(jù)回填到 Redis。正常請求用戶 - Redis命中 - 返回 緩存未命中用戶 - Redis未命中 - MySQL - 回填 Redis - 返回這個流程看起來沒有問題但里面藏著一個漏洞當(dāng)查詢的 key 在 Redis 和 MySQL 中都不存在時緩存層就沒有任何作用了。攻擊者構(gòu)造一個不存在的商品 ID比如 99999999。你的程序查 Redis發(fā)現(xiàn)沒有這個 key于是去查 MySQLMySQL 也查不到程序返回“商品不存在”同時也不會寫入緩存。下一次請求同樣的 ID程序再查 Redis還是沒有再去查 MySQL。每一次請求都穿越了緩存直達(dá)數(shù)據(jù)庫。攻擊者不需要費多大力氣只要用腳本循環(huán)遍歷一批不存在的 ID就能把你數(shù)據(jù)庫的 QPS 打滿。這就是“緩存穿透”這個名稱的由來流量繞過了緩存這層盾牌直接穿透到了數(shù)據(jù)庫身上。真正容易踩坑的地方是很多人以為緩存穿透是 Redis 配置問題或者緩存中間件的問題其實完全不是。緩存組件本身工作正常它只是沒有能力擋住“查不到數(shù)據(jù)”的請求因為這類請求天然無法被緩存命中。這是一個分布式系統(tǒng)防御設(shè)計的問題而不是緩存組件故障的問題。從本質(zhì)上看緩存穿透之所以危險是因為它把數(shù)據(jù)庫暴露在了無差別流量的沖擊之下。數(shù)據(jù)庫的性能是有限的它的連接數(shù)、線程數(shù)、磁盤 IO 都有上限而攻擊者制造無效請求的成本幾乎為零。你越依賴數(shù)據(jù)庫數(shù)據(jù)庫就越脆弱你越依賴緩存緩存就越容易被“查無此 key”的流量繞過。要解決這個問題核心邏輯有三條路第一讓緩存能夠處理“查到空結(jié)果”的情況第二在查詢緩存之前用更廉價的數(shù)據(jù)結(jié)構(gòu)判斷這個 key 到底存不存在第三在接口層限制可疑流量的訪問頻率。后面三個章節(jié)會逐一展開。2. 緩存穿透、緩存擊穿、緩存雪崩三個概念別再傻傻分不清在講方案之前必須先厘清三個經(jīng)常一起出現(xiàn)的概念。很多人在面試?yán)锬鼙吵龆x一到排查問題時就把它們混為一談最終導(dǎo)致方案用錯。概念關(guān)鍵特征觸發(fā)條件典型解決思路緩存穿透查詢的數(shù)據(jù)在緩存和數(shù)據(jù)庫中都不存在惡意請求遍歷不存在的 ID緩存空值、布隆過濾器、參數(shù)校驗、限流緩存擊穿某個熱點 key 過期瞬間大量請求同時打到數(shù)據(jù)庫熱點數(shù)據(jù)過期且并發(fā)極高互斥鎖、邏輯過期、熱點數(shù)據(jù)預(yù)熱緩存雪崩大量 key 同時過期導(dǎo)致數(shù)據(jù)庫瞬間壓力暴增大批 key 設(shè)置了相同的過期時間過期時間加隨機值、多級緩存、熔斷降級三者的區(qū)別用場景來理解最直觀。緩存穿透是“打了一個不存在的靶子”靶子本來就不在所以緩存永遠(yuǎn)擋不住。緩存擊穿是“打一個很熱的靶子但靶子剛好被撤了下來”也就是熱點 key 在過期的一瞬間緩存失效并發(fā)請求全部落到數(shù)據(jù)庫。緩存雪崩則是“所有靶子一起被撤下來”大量 key 在同一時間過期數(shù)據(jù)庫承受不了瞬間的請求洪峰。從解決方向上看三者完全不同。緩存穿透的核心是“如何低成本地判斷 key 不存在”緩存擊穿的核心是“如何保證熱點 key 過期時只有一個請求去重建緩存”緩存雪崩的核心是“如何避免過期時間過于集中”。本文只解決緩存穿透但你需要知道它的邊界。一個完整的緩存防護體系往往需要同時考慮穿透、擊穿和雪崩少了任何一個環(huán)節(jié)數(shù)據(jù)庫都可能被找到新的突破口。3. 最容易被打穿的業(yè)務(wù)場景哪些項目風(fēng)險最高并非所有項目都會遇到緩存穿透。它通常需要滿足兩個條件一是業(yè)務(wù)中存在“查詢不到數(shù)據(jù)”的合法場景二是接口接收外部傳入的 ID 或者編碼。如果你的系統(tǒng)滿足這兩個條件那么緩存穿透就只是一個時間問題。以下四類場景是最常見的重災(zāi)區(qū)。商品詳情類接口。商品 ID 是用戶可猜測的而且商品可能存在下架、刪除等狀態(tài)。攻擊者只需要從 1 開始遞增遍歷就能制造大量不存在的 ID。電商大促期間這類接口往往沒有嚴(yán)格限流一旦被打穿數(shù)據(jù)庫會立刻成為瓶頸。訂單查詢類接口。訂單號通常是業(yè)務(wù)號可預(yù)測性較強。很多系統(tǒng)在查詢訂單時先查緩存再查數(shù)據(jù)庫最后返回“訂單不存在”。但一個不存在的訂單號依然會觸發(fā)完整的數(shù)據(jù)庫查詢鏈路。用戶 Token 或賬號校驗。這類接口使用頻繁流量大而且外部攻擊者可以隨機生成無效 Token 來試探。每一次無效 Token 校驗都會穿透緩存直接把壓力施加到用戶表或登錄日志表上。短鏈解析和邀請碼核銷類業(yè)務(wù)。短鏈碼、邀請碼的字符空間有限攻擊者可以批量遍歷。如果數(shù)據(jù)庫中沒有對應(yīng)記錄緩存又無法命中請求就會全部打到數(shù)據(jù)庫。這些場景有一個共同特點接口對外開放參數(shù)可預(yù)測業(yè)務(wù)存在“查不到是正常情況”的語義。只要你的系統(tǒng)滿足這三個條件就必須主動考慮緩存穿透防護而不是等監(jiān)控報警之后再去救火。另外還要警惕一種容易忽略的情況業(yè)務(wù)邏輯里“軟刪除”的數(shù)據(jù)。比如商品狀態(tài)被置為 1已刪除查詢主流程可能不會返回但數(shù)據(jù)庫里確實存在這條記錄。如果查詢條件只過濾狀態(tài)位不帶主鍵白名單這類數(shù)據(jù)也會表現(xiàn)出“查不到”的特征從而成為穿透流量的目標(biāo)。4. 方案一緩存空值給不存在的 key 也安排一個座位緩存穿透最直接的原因是“查不到的數(shù)據(jù)無緩存可命”。那么思路自然就來了既然查不到那我把“查不到”這個結(jié)果也緩存起來問題不就解決了嗎這就是緩存空值方案。4.1 原理與實現(xiàn)思路當(dāng)數(shù)據(jù)庫查詢結(jié)果為空時不要直接返回而是把一個特殊標(biāo)記寫入緩存并設(shè)置一個較短的過期時間。這樣下一次同樣的 key 過來緩存能命中這個空值標(biāo)記接口直接返回“不存在”不再查詢數(shù)據(jù)庫。關(guān)鍵代碼如下// 文件路徑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 步參數(shù)校驗后面會細(xì)講 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) { // 緩存數(shù)據(jù)損壞時按穿透處理回源數(shù)據(jù)庫 redisTemplate.delete(cacheKey); } } // 第 3 步查數(shù)據(jù)庫 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; } // 真實數(shù)據(jù)緩存 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) { // 查詢結(jié)果為空返回 null 給上層做空值緩存 return null; } } }4.2 這里真正容易踩坑的地方緩存空值方案實現(xiàn)簡單效果立竿見影但它有幾個容易被忽略的坑。第一個坑是空值 key 占內(nèi)存。惡意流量遍歷 100 萬個不存在的 ID就會在 Redis 中產(chǎn)生 100 萬個空值 key。這些 key 雖然設(shè)置了過期時間但在過期之前依然占用內(nèi)存。如果業(yè)務(wù)量大Redis 內(nèi)存會快速上漲。解決辦法是給空值 key 設(shè)置統(tǒng)一前綴比如null:后續(xù)可以寫定時任務(wù)批量清理或者降低空值緩存時間。第二個坑是空值緩存時間不宜過長。如果你把不存在的商品 ID 緩存 30 分鐘而商品剛好在 10 分鐘后被重新上架用戶在 20 分鐘內(nèi)仍然查不到這個商品。這會直接導(dǎo)致數(shù)據(jù)一致性問題而且很難排查。因此空值緩存時間建議控制在 2 到 5 分鐘加上隨機抖動既起到防穿透作用又能接受短時間內(nèi)的數(shù)據(jù)延遲。第三個坑是要區(qū)分“緩存空值”和“緩存數(shù)據(jù)異?！?。當(dāng)緩存中讀取到EMPTY_MARK時返回空結(jié)果當(dāng)讀到非空字符串但 JSON 解析失敗時說明緩存數(shù)據(jù)已經(jīng)損壞應(yīng)該刪除緩存并回源數(shù)據(jù)庫而不是直接返回“不存在”。這段邏輯在示例代碼中已經(jīng)體現(xiàn)出來很多初學(xué)者會漏掉。緩存空值適合的業(yè)務(wù)形態(tài)是數(shù)據(jù)量不大、攻擊流量有限、希望快速落地解決。它是防穿透方案的“下限”幾乎每個項目都應(yīng)該先做這一步。5. 方案二布隆過濾器把非法 key 攔截在查詢之前緩存空值方案是事后攔截請求先打到緩存發(fā)現(xiàn)沒命中然后緩存空值把后續(xù)請求擋住。但空值 key 本身還會短暫占內(nèi)存而且如果攻擊流量在空值過期后再次發(fā)起依然會穿透。布隆過濾器則是一種前置攔截方案在查緩存之前先判斷 key 到底存不存在如果過濾器認(rèn)為不存在直接返回連 Redis 都不查。5.1 布隆過濾器是怎么工作的布隆過濾器是一個非常節(jié)省內(nèi)存的概率性數(shù)據(jù)結(jié)構(gòu)。它的核心邏輯是把所有合法 key 通過多個哈希函數(shù)映射到一個很長的位數(shù)組上在位數(shù)組中把對應(yīng)位置置為 1。查詢時同樣計算多個哈希值如果所有對應(yīng)位置都是 1則認(rèn)為 key “可能存在”只要有任何一個位置為 0則可以確定 key “一定不存在”。簡單理解它是一個“大概率在名單里”的檢查員。如果它說“不在”那就一定不在如果它說“在”只是大概率在也有小概率誤判。對于緩存穿透場景這個特性非常合適。我們只關(guān)心“這個 ID 到底是不是合法商品 ID”如果一個 ID 被過濾器判定為不存在就直接返回“商品不存在”根本不用繼續(xù)查緩存和數(shù)據(jù)庫。即使誤判了一個不存在的 ID 為可能存在最壞的結(jié)果也就是多查一次數(shù)據(jù)庫不會返回錯誤結(jié)果。5.2 使用 Guava 實現(xiàn)布隆過濾器在 Java 項目中最常用的布隆過濾器實現(xiàn)是 Google Guava。以下代碼示例展示了如何在應(yīng)用啟動時加載所有商品 ID并在查詢時進行過濾判斷// 文件路徑src/main/java/com/example/demo/filter/ProductBloomFilter.java Component public class ProductBloomFilter { // 預(yù)計要放入過濾器的元素數(shù)量 private static final int EXPECTED_INSERTIONS 100000; // 誤判率越低越占內(nèi)存這里設(shè)置為 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; } // 后續(xù)查緩存、查數(shù)據(jù)庫的邏輯保持不變 }5.3 布隆過濾器的局限與更新策略布隆過濾器也不是銀彈使用它之前必須想清楚數(shù)據(jù)更新策略。最大的問題在于新增數(shù)據(jù)的同步。布隆過濾器在應(yīng)用啟動時一次性加載所有商品 ID但業(yè)務(wù)是動態(tài)的每天都會有新商品上架。如果新增商品后沒有把新 ID 放入過濾器這個新商品會被誤判為“不存在”用戶永遠(yuǎn)查不到。解決做法有三種增量更新在商品創(chuàng)建的 Service 方法中同步調(diào)用bloomFilter.put(id)。實現(xiàn)簡單但需要保證業(yè)務(wù)代碼中所有創(chuàng)建入口都不遺漏一旦遺漏就會產(chǎn)生線上問題。定時全量重建每天凌晨從數(shù)據(jù)庫重新加載全部商品 ID構(gòu)建新的過濾器。需要解決新舊過濾器切換的問題可以用雙緩沖即維護兩份過濾器重建完成后切換引用。混合策略增量更新保證實時性定時重建兜底防止增量遺漏積累。另一個局限性是過濾器啟動加載大 key 集合時耗時較長。如果平臺有上億商品數(shù)據(jù)一次性加載可能耗時幾分鐘。可以考慮只用熱點或高權(quán)重商品的 ID 構(gòu)建過濾器或使用 Redis 的 BitMap 實現(xiàn)分布式布隆過濾器避免單應(yīng)用內(nèi)存受限。布隆過濾器適用的業(yè)務(wù)形態(tài)是數(shù)據(jù)量大、相對穩(wěn)定、存在可預(yù)知的合法 key 全集并且希望把無效流量在 Redis 之前就攔截掉。在中小項目里它不是第一優(yōu)先級但在高并發(fā) C 端系統(tǒng)中它通常是防穿透體系里最前面的一道閘門。6. 方案三接口層防護流量層面的最后一道保險緩存空值和布隆過濾器解決的是“數(shù)據(jù)層面”的穿透問題但還有一個維度需要防守如果攻擊者流量足夠大即使每個 key 只查一次數(shù)據(jù)庫也能把你的數(shù)據(jù)庫打掛。這時候光靠緩存層的方案就不夠了還需要在接口層和流量層做防護。6.1 參數(shù)校驗是第一道口子很多緩存穿透事故的根源是接口沒有對入?yún)⒆龌拘ｒ炄魏螖?shù)字都可以進入查詢鏈路。先看你的接口是不是也存在這種情況。一個商品 ID 不可能小于等于 0不可能超過某個合理的業(yè)務(wù)范圍也通常不會是負(fù)數(shù)。如果這些非法參數(shù)都能直接進入 Service 層說明你的參數(shù)校驗還不到位。在 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); }注意參數(shù)校驗只是過濾掉“明顯非法”的請求并不能防御“ID 本身合法但商品不存在”的穿透流量。所以參數(shù)校驗是地基但不能只靠它。6.2 基于 key 維度的限流把惡意請求擋在業(yè)務(wù)邏輯之外限流是接口層保護數(shù)據(jù)庫的關(guān)鍵手段。我們的目標(biāo)是對同一個 key 的訪問頻率進行限制一旦超過閾值直接拒絕請求。在實踐中更專業(yè)的做法是基于 Redis 的滑動窗口或者令牌桶實現(xiàn)分布式限流。這里先給一個本地內(nèi)存版的時間窗口限流示例雖然只適用于單機演示但限流思路和代碼結(jié)構(gòu)完全一樣// 文件路徑src/main/java/com/example/demo/limit/KeyRateLimiter.java Component public class KeyRateLimiter { // key - 訪問時間戳隊列 private final ConcurrentHashMapString, DequeLong visitWindow new ConcurrentHashMap(); // 每個 key 在 60 秒內(nèi)最多允許訪問 50 次 private static final int LIMIT 50; private static final long WINDOW_MILLIS 60_000L; /** * 檢查當(dāng)前 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; } }然后在查詢商品前先判斷當(dāng)前 key 是否已經(jīng)被限流Autowired private KeyRateLimiter keyRateLimiter; public Product getProductById(Long id) { String rateLimitKey rate:product: id; if (keyRateLimiter.isOverLimit(rateLimitKey)) { throw new BizException(請求過于頻繁請稍后重試); } // 其余查詢邏輯不變 }這個本地實現(xiàn)有幾個明顯問題第一它只在單機內(nèi)存中生效多實例部署時必須換成 Redis Lua 實現(xiàn)第二它把同一個 key 的正常并發(fā)請求也限住了比如秒殺活動中有 1000 人同時搶購?fù)粋€商品第一個請求到達(dá)后后面 949 個請求都會被誤傷。因此限流閾值必須根據(jù)業(yè)務(wù)壓測結(jié)果來決定并且針對搶購等熱點場景要單獨設(shè)計。6.3 限流解決的是“惡意流量”問題而不是“數(shù)據(jù)不存在”問題需要說明的是接口限流并不能在數(shù)據(jù)結(jié)構(gòu)層面解決緩存穿透它的作用是當(dāng)緩存層和布隆過濾器都被繞過時限制攻擊速率避免數(shù)據(jù)庫瞬間被打掛。一套完整的接口防護還應(yīng)該包括IP 維度的限流、用戶維度的限流、短期失敗次數(shù)的黑名單機制以及第一時間對異常流量來源進行告警。這些能力通常由網(wǎng)關(guān)層承擔(dān)但如果你沒有網(wǎng)關(guān)這些邏輯就必須寫在應(yīng)用層。接口層防護適用任何對外提供服務(wù)的系統(tǒng)。它不一定能完全消除穿透流量但它能保證你的數(shù)據(jù)庫在最壞情況下依然有喘息的空間。7. 三種方案選型對比別把全部武器一次堆上去講了三種方案你可能會糾結(jié)到底該用哪一種。這里做一個直接了當(dāng)?shù)倪x型建議。方案實現(xiàn)成本對內(nèi)存的占用防穿透效果誤傷/數(shù)據(jù)風(fēng)險適用階段緩存空值低較高空值 key 也會占內(nèi)存好能擋住重復(fù)無效請求低但存在短暫的數(shù)據(jù)一致性問題中小項目、快速上線兜底布隆過濾器中低位數(shù)組非常省內(nèi)存好能在緩存之前攔截大部分無效 key如果新增數(shù)據(jù)不同步會“誤殺”真實數(shù)據(jù)數(shù)據(jù)量大、key 集合穩(wěn)定的系統(tǒng)接口限流與參數(shù)校驗中高低輔助性兜底不能根除穿透閾值設(shè)置不當(dāng)會誤傷正常用戶公網(wǎng)接口、惡意攻擊場景從實踐角度看我建議按業(yè)務(wù)體量分三檔來選第一檔剛起步的項目或者內(nèi)部系統(tǒng)直接做參數(shù)校驗 緩存空值。不要引入布隆過濾器因為動態(tài)數(shù)據(jù)同步的成本比收益還高。緩存空值能擋住 90% 的重復(fù)穿透流量足夠應(yīng)對常規(guī)風(fēng)險。第二檔有一定流量的 C 端系統(tǒng)參數(shù)校驗 緩存空值 接口限流。重點是限流閾值要經(jīng)過壓測不能拍腦袋。這個組合能應(yīng)對大多數(shù)惡意遍歷場景。第三檔大規(guī)模高并發(fā)平臺在前兩檔基礎(chǔ)上增加布隆過濾器并配套完善的數(shù)據(jù)同步機制。同時把限流下沉到網(wǎng)關(guān)層應(yīng)用層只保留業(yè)務(wù)校驗和最后的保護邏輯。這里有一個常見的決策誤區(qū)很多人喜歡一次性把三種方案都堆上去覺得越多的方案越安全。但實際上每多一個組件就多一份維護成本和一個故障點。布隆過濾器的誤殺風(fēng)險、限流的誤傷風(fēng)險都比緩存空值更隱蔽如果團隊沒有足夠的監(jiān)控和快速回滾能力不建議在項目初期就全量上線。記住一句話緩存空值是兜底布隆過濾器是攔截限流是保命。三個方案不是互相替代的關(guān)系而是按風(fēng)險等級逐層設(shè)防的關(guān)系。8. 完整實戰(zhàn)Spring Boot 集成緩存空值與接口限流前面講完了原理和選型這一節(jié)提供一個可以直接運行的 Spring Boot 示例工程。示例會組合“參數(shù)校驗 緩存空值 本地 key 維度限流”三套邏輯并附加布隆過濾器的可選接入方式方便你對照練習(xí)。8.1 環(huán)境準(zhǔn)備與項目結(jié)構(gòu)本文示例以 Spring Boot 3.2.x 為基礎(chǔ)使用 JDK 17操作系統(tǒng)不限。Redis 建議使用 5.0 以上版本MySQL 使用 5.7 或 8.0 均可。如果你本機沒有 MySQL也可以用內(nèi)存數(shù)據(jù)庫 H2 代替SQL 部分需要做少量調(diào)整。!-- 文件路徑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示例工程結(jié)構(gòu)如下src/main/java/com/example/demo ├── CachePenetrationDemoApplication.java ├── controller │ └── ProductController.java ├── service │ └── ProductService.java ├── entity │ └── Product.java ├── limit │ └── KeyRateLimiter.java └── common └── Result.java8.2 核心代碼實現(xiàn)產(chǎn)品實體類// 文件路徑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; } }統(tǒng)一返回體// 文件路徑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; } }產(chǎn)品 Service組合了參數(shù)校驗、緩存空值和限流邏輯// 文件路徑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 可選的布隆過濾器接入方式如果你在真實項目中決定使用布隆過濾器可以在上述工程基礎(chǔ)上增加ProductBloomFilter類然后在ProductService.getProductById的最前面增加一次判斷。注意只有在你能保證商品 ID 增量同步到過濾器時才建議開啟否則不要貿(mào)然接進去。// 文件路徑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); } }接入查詢服務(wù)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 初始化數(shù)據(jù)表執(zhí)行下面的 SQL 創(chuàng)建商品表并插入兩條測試數(shù)據(jù)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. 運行結(jié)果與效果驗證啟動 Redis 和 MySQL 后在項目根目錄執(zhí)行mvn spring-boot:run應(yīng)用啟動成功后用 curl 驗證效果。第一次查詢存在的商品 IDcurl http://localhost:8080/product/1預(yù)期返回{code:200,message:success,data:{id:1,name:iPhone 15 Pro,price:8999.00}}連續(xù)查詢第二次Redis 中已經(jīng)有緩存觀察日志會發(fā)現(xiàn)不會再次查詢數(shù)據(jù)庫。查詢不存在的商品 IDcurl http://localhost:8080/product/999第一次會查數(shù)據(jù)庫并寫入空值緩存。預(yù)期返回{code:500,message:商品不存在,data:null}然后再次請求相同的 ID預(yù)期返回結(jié)果相同但數(shù)據(jù)庫不會收到新的查詢。可以到 Redis 中確認(rèn)空值 key 已寫入redis-cli 127.0.0.1:6379 GET product:detail:999 EMPTY 127.0.0.1:6379 TTL product:detail:999 (integer) 172驗證限流在短時間內(nèi)用同一個不存在的 ID 連續(xù)請求超過 50 次預(yù)期會看到接口返回“請求過于頻繁請稍后重試”。如果需要模擬真實壓測效果可以用ab等工具對同一個不存在的 ID 發(fā)起高頻請求同時觀察數(shù)據(jù)庫的查詢?nèi)罩净蛘呗罩?。你會發(fā)現(xiàn)在沒有空值緩存之前每一次請求都會落到數(shù)據(jù)庫而接入空值緩存和限流之后除了第一批請求后續(xù)請求都被 Redis 和限流邏輯攔截了。ab -n 10000 -c 100 http://localhost:8080/product/999判斷成功的標(biāo)準(zhǔn)有三個第一應(yīng)用日志中 MySQL 查詢次數(shù)不再隨請求數(shù)線性增長第二Redis 中空值 key 數(shù)量保持穩(wěn)定第三數(shù)據(jù)庫連接池水位和 QPS 沒有明顯波動。10. 常見問題與排查思路下面整理了緩存穿透防護落地過程中比較常見的幾類問題大家可以對照排查。問題現(xiàn)象可能原因排查方式解決方案Redis 內(nèi)存快速上漲空值 key 過多用redis-cli --bigkeys或SCAN統(tǒng)計空值前綴 key 數(shù)量降低空值過期時間寫清理任務(wù)清理null:前綴 key或考慮布隆過濾器前置攔截新上架商品查詢返回“不存在”布隆過濾器沒有同步增量 ID查看商品創(chuàng)建方法中是否調(diào)用了put方法在創(chuàng)建入口同步更新過濾器或采用定時全量重建策略正常用戶請求被限流誤傷限流閾值設(shè)置過低查看限流日志和 QPS 峰值根據(jù)壓測數(shù)據(jù)調(diào)整閾值對搶購熱點單獨配置或改用令牌桶算法空值緩存過期后再次打爆數(shù)據(jù)庫空值時間太短攻擊流量持續(xù)查看 Redis 空值 key 的過期時間和 DB QPS 曲線調(diào)長空值緩存時間并加隨機抖動疊加布隆過濾器攔截并發(fā)第一次請求時數(shù)據(jù)庫瞬間沖高緩存未命中時沒有互斥重建查看 DB QPS 峰值與 Redis key 過期時間是否對應(yīng)對緩存重建增加分布式鎖同一 key 只允許一個線程查 DB商品數(shù)據(jù)庫更新后緩存還是舊值緩存沒有及時失效檢查更新方法是否刪除緩存采用 Cache Aside 模式先更新數(shù)據(jù)庫再刪除緩存并做好重試機制排查時有一個基本順序先看 Redis 緩存是否生效再看空值 key 是否存在再看限流日志最后才去翻數(shù)據(jù)庫慢查詢?nèi)罩尽：芏鄦栴}并不是第一層防線失效而是多層防線中的某一層配置出了問題逐層檢查能快速縮小范圍。11. 生產(chǎn)環(huán)境最佳實踐從“能防”到“防得住”方案落地之后更重要的是把防護體系變成可持續(xù)運行的生產(chǎn)能力。從工程實踐角度看有四個方向值得投入。第一個方向是監(jiān)控指標(biāo)。緩存穿透防護是否生效不能靠感覺要靠數(shù)據(jù)。建議至少監(jiān)控以下指標(biāo)Redis 緩存命中率、數(shù)據(jù)庫查詢 QPS、空值 key 數(shù)量、限流拒絕次數(shù)。其中空值 key 數(shù)量是一個很敏感的指標(biāo)如果它在短時間內(nèi)急劇增長說明要么有攻擊流量要么業(yè)務(wù)上出現(xiàn)了大量無效查詢需要第一時間告警。第二個方向是緩存過期時間的隨機性。無論是真實數(shù)據(jù)還是空值緩存過期時間都要加隨機抖動。如果所有 key 都在同一秒過期緩存穿透問題還沒解決就可能先引發(fā)緩存雪崩。隨機值的范圍可以參考基礎(chǔ)過期時間的 10% 到 30%。第三個方向是優(yōu)雅降級。在極端情況下即使有緩存空值和布隆過濾器數(shù)據(jù)庫仍可能因為瞬時流量過大而瀕臨崩潰。此時需要應(yīng)用層具備快速降級能力對非核心接口直接返回降級數(shù)據(jù)對核心接口啟用簡化版查詢必要時直接熔斷數(shù)據(jù)庫查詢先保住系統(tǒng)可用性再恢復(fù)數(shù)據(jù)一致性。第四個方向是全鏈路壓測。不要在事故發(fā)生后才驗證方案是否有效。上線前用 ab、JMeter 或 Locust 模擬高頻穿透流量觀察數(shù)據(jù)庫 QPS 和連接池水位。壓測目標(biāo)不是“不報錯”而是“在攻擊流量翻倍時數(shù)據(jù)庫依然有冗余容量”。如果你發(fā)現(xiàn)數(shù)據(jù)庫 QPS 已經(jīng)打滿說明防線層級不夠需要繼續(xù)往前加攔截。第五個方向是安全邊界。對于公網(wǎng)接口建議在網(wǎng)關(guān)層增加 IP 維度的限流和黑名單機制并記錄攻擊特征。對明顯的遍歷行為比如短時間內(nèi)大量不同 ID 的 404 請求可以自動識別并加入臨時黑名單。這些機制的實現(xiàn)成本和運維成本不低但一旦遇到惡意攻擊它們往往是保護數(shù)據(jù)庫不被拖垮的關(guān)鍵。12. 最后要說的話緩存穿透從來都不是緩存的錯而是你的系統(tǒng)在數(shù)據(jù)訪問鏈路上缺少“安保意識”。如果把數(shù)據(jù)庫比作一家銀行的金庫緩存就是金庫外面的接待大廳而布隆過濾器是大門處的安檢員緩存空值是給“找不到人”的情況做的登記簿限流則是保安隊伍。每一層防線都有自己的作用少了任何一層金庫的直接暴露風(fēng)險都會升高。如果你是在接手一個老項目我建議先不要急著把三種方案全部堆上去。第一步翻一翻線上日志確認(rèn)是否存在大量“查無此數(shù)據(jù)”的重復(fù)請求第二步把接口參數(shù)校驗補上給每個讀接口加一個合理的邊界約束第三步實現(xiàn)緩存空值這是投入產(chǎn)出比最高的一步。等觀察一段時間確認(rèn)確實存在惡意穿透流量再逐步引入布隆過濾器和分布式限流。數(shù)據(jù)庫是慢變量保護它的關(guān)鍵永遠(yuǎn)是把流量擋在更前面的位置。希望這篇文章能幫你少踩一個洞也少熬一個夜。