乙個一定不存在快取及查詢不到的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。
有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一定不存在的資料會被 這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。另外也有乙個更為簡單粗暴的方法（我們採用的就是這種），如果乙個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。
粗暴方式偽**：
//偽**
public object getproductlistnew()
cachevalue = cachehelper.get(cachekey);
if (cachevalue != null) else
cachehelper.add(cachekey, cachevalue, cachetime);
return cachevalue;}}
使用互斥鎖(mutex key)
業界比較常用的做法，是使用mutex。簡單地來說，就是在快取失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用快取工具的某些帶成功操作返回值的操作（比如redis的setnx或者memcache的add）去set乙個mutex key，當操作返回成功時，再進行load db的操作並回設快取；否則，就重試整個get快取的方法。
setnx，是「set if not exists」的縮寫，也就是只有不存在的時候才設定，可以利用它來實現鎖的效果。
public string get(key) else
} else
}
if (memcache.get(key) == null) else
}
快取正常從redis中獲取，示意圖如下：
快取失效瞬間示意圖如下：
快取失效時的雪崩效應對底層系統的衝擊非常可怕！大多數系統設計者考慮用加鎖或者佇列的方式保證來保證不會有大量的執行緒對資料庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層儲存系統上。還有乙個簡單方案就時講快取失效時間分散開，比如我們可以在原有的失效時間基礎上增加乙個隨機值，比如1-5分鐘隨機，這樣每乙個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。
加鎖排隊，偽**如下：
//偽**
public object getproductlistnew() else else
}return cachevalue;}}
注意：加鎖排隊的解決方式分布式環境的併發問題，有可能還要解決分布式鎖的問題；執行緒還會被阻塞，使用者體驗很差！因此，在真正的高併發場景下很少使用！
隨機值偽**：
//偽**
public object getproductlistnew() else );
return cachevalue;}}
針對業務系統，永遠都是具體情況具體分析，沒有最好，只有最合適。
於快取其它問題，快取滿了和資料丟失等問題，大夥可自行學習。最後也提一下三個詞lru、rdb、aof，通常我們採用lru策略處理溢位，redis的rdb和aof持久化策略來保證一定情況下的資料安全。
redis 快取擊穿和快取穿透
布隆過濾器 快取擊穿 總結有很多使用者，請求介面。為了防止mysql壓力過大，在訪問量很大且資料變動不頻繁的情況下，我們通過增加redis快取減少mysql的壓力。正常的流程為下圖所示。redis中無資料，從mysql中查詢 mysqlserver mysqli connect 127.0.0.1 ...
Redis 快取穿透 快取擊穿 快取雪崩
快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷發起請求，如發起為id為小於0的資料或id為特別大等不存在的資料。這時的使用者很可能是攻擊者，攻擊會導致資料庫壓力過大。舉例 通過分類id查詢廣告集合 param categoryid 廣告分類id return 廣告集合 public listf...
Redis快取穿透 快取擊穿 快取雪崩
4 總結 一般企業都會用到mysql等關係型資料庫，當訪問量不大的時候還可以支撐 當併發量高的時候，比如商品搶購或者主頁訪問瞬間較大的時候，請求直接到達db，可能會導致系統效能急劇下降以致癱瘓。db是面向磁碟的，磁碟io是比較重的操作，效能較低。為了克服上述的問題，通常需要在客戶端和db之間引入一層...