快取穿透

現象

查詢一個一定不存在的資料，由於每次查詢的時候快取中查詢不到，就會到資料庫中查詢。資料庫中也沒有查詢到，所以每次返回null，查不到資料則不能更新到快取中，導致每次查詢這個資料的時候，都透過快取到資料庫中查詢，這種現象就成為快取穿透。

解決方案

如果一個查詢返回的資料為空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。

快取雪崩

現象

如果快取集中在某段時間內，發生大量的快取穿透，所有的查詢都在資料上進行，導致快取雪崩，資料量壓力驟增。這個沒有完美的解決方案，可以分析使用者的行為，儘量讓快取失效的時間點均有分佈。多數系統設計者考慮用加鎖或者佇列的方式保證快取的單執行緒（程序）寫，從而避免失效時大量的併發請求落到底層儲存系統上。

解決方案

1. 不同的key設定不同的失效時間，儘量讓快取失效時間均勻分佈。
2. 做二級快取或者雙快取策略。A1為原始快取，A2為拷貝快取，A1失效的時候可以訪問A2,。A1快取失效時間設定為短期，A2快取失效的時間設定較長。
3. 可以通過快取的reload機制預先去更新快取，也可以在即將發生大量高併發的時候，手動觸發去載入快取。
4. 快取失效後，通過佇列或者加鎖來控制對資料庫訪問的併發量，比方說對某個key的讀操作或者寫操作都控制在單執行緒進行，其他執行緒等待的狀態下。