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