查詢資料庫中一定不存在的資料，使用者發出查詢請求，根據引數（主鍵id）首先根據key去查詢redis，發現為空，接著查詢資料庫發現沒有結果，然後不會往redis中存入任何資料，接下來所有的請求都會往復進行，都會訪問資料庫，造成資料庫壓力。
解決快取穿透，可以在第一次查詢資料庫時，如果返回空，則在redis中快取空值，可以設定短暫的過期時間，如60秒。
快取資料在同一時間段內集體過期失效。
產生雪崩的原因，比如雙十一，大搶購，一大批商品快取進redis，時間為1小時，那麼在一點的時候大量快取將會失效，然後對這批商品的訪問壓力將會來到資料庫上了。
這個時候解決的辦法是，將不同分類的商品進行不同的快取週期。在同一分類的商品，給快取週期加上乙個隨機因子，經量分散資料快取到期時間。熱門類目快取時間長一些，冷門商品快取時間短一些，節約伺服器資源。
若是因為伺服器宕機導致的快取雪崩，則需要採用redis的主備模式，在主伺服器宕機時，馬上使用從伺服器進行工作。
乙個熱門key，在不停扛著大量併發，大量併發集中對這乙個點集中訪問，當key短暫失效的瞬間，大量的訪問擊穿快取，訪問壓力來到資料庫，就像在螢幕上鑿穿了乙個洞一樣。
可以在查詢時，使用互斥鎖（synchronized），當第乙個執行緒查詢完畢，並將資料快取到快取中，然後釋放了鎖，剩下的執行緒才可以便可直接去快取中獲取資料。
對於熱門商品的訪問可以將快取的快取時間設定為永久。
參考鏈結
Redis快取穿透和快取雪崩
了解過redis的人都知道，在執行讀操作 查詢等 的時候會先從快取中讀取，快取中沒有的話再去資料庫中查詢。如下圖 概念 使用者想要查詢乙個資料，發現redis快取中沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當使用者很多的時候，快取都沒有命中 如秒殺 於是都去請求...
redis快取雪崩和快取穿透
快取雪崩 由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io 記憶體和cpu眼裡過大，甚至導致宕機，使得整個系統崩潰。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓...
Redis 快取穿透 快取雪崩和快取擊穿
快取穿透，是指查詢乙個資料庫一定不存在的資料。正常的使用快取流程大致是，資料查詢先進行快取查詢，如果key不存在或者key已經過期，再對資料庫進行查詢，並把查詢到的物件，放進快取。如果資料庫查詢物件為空，則不放進快取。流程 引數傳入物件主鍵id 根據key從快取中獲取物件 如果物件不為空，直接返回 ...