指查詢乙個一定不存在的資料，由於快取中沒有該查詢物件（快取始終無法命中對應的資料），這時會去資料庫查詢資料，如果資料庫中也沒有對應的資料也無法寫入快取，在這種情況下，每一次查詢不存在資料的請求都將去查詢資料庫，這就是快取穿透。
造成影響：
當在高併發的情況下，快取穿透可能會拖慢資料庫，進而拖慢整個系統，甚至宕機。
解決辦法：
當在快取中無法命中對應資料時，且訪問資料庫也沒有查詢到目標資料，這時向快取中存入空結果。這樣的情況下，每一次查詢首先判斷redis中是否有目標資料（即exist(string key)），key存在就直接返回快取結果，即使快取結果是空值。
當大量快取在同一時間段內失效的時候，會在這段時間內引發大量資料庫訪問查詢，給資料庫帶來較大的壓力。
解決辦法：
在資料庫訪問層面，加鎖/佇列式的穿行訪問
分析系統快取實際情況（包括使用者使用場景等），設計分布較為均勻的失效時間。
資料預熱，在能遇見的併發高峰來臨前，提前均勻的、有計畫的更新快取資料，防止在併發高峰期出現快取大量失效的情況。
設定業務熱點資料永不過期，只做快取更新操作
在分布式資料庫的情況下，將熱點資料均勻分布，分散快取雪崩後帶來的單個資料庫訪問壓力
訪問限流（最不推薦）
這裡比較推薦通過使用 2 、3 、4 方法來預防解決快取雪崩問題，加鎖或者是佇列式的訪問控制，一定會帶來效能的損耗，能提前避免的問題就盡量提前避免，最好不要等到意外發生了再做補救。
雙重檢測鎖：
public user selectbyid(string id) }}
return user;
}
Redis快取穿透和快取雪崩
了解過redis的人都知道，在執行讀操作 查詢等 的時候會先從快取中讀取，快取中沒有的話再去資料庫中查詢。如下圖 概念 使用者想要查詢乙個資料，發現redis快取中沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中 如秒殺 於是都去請求...
redis快取雪崩和快取穿透
快取雪崩 由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io 記憶體和cpu眼裡過大，甚至導致宕機，使得整個系統崩潰。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓...
Redis 快取穿透 快取雪崩和快取擊穿
快取穿透，是指查詢乙個資料庫一定不存在的資料。正常的使用快取流程大致是，資料查詢先進行快取查詢，如果key不存在或者key已經過期，再對資料庫進行查詢，並把查詢到的物件，放進快取。如果資料庫查詢物件為空，則不放進快取。流程 引數傳入物件主鍵id 根據key從快取中獲取物件 如果物件不為空，直接返回 ...