一、什麼是快取穿透？

快取未命中某key，轉而到db中查詢。

快取穿透的漏洞

惡意利用不存在的key頻繁攻擊應用，導致請求直接落到DB中，可能導致DB瞬時高負載或掛掉。

快取穿透解決方案一：

先查詢快取，若快取為null，則查詢db，若DB仍返回無結果，將該key寫入快取，標識為不存在key（例如將對應v設定成統一值，標識該v的所有keyDB中不存在），同樣key再訪問應用時，查詢快取！=null 且 = &&直接返回null，從而減少對db的請求。 

不存在key在快取中如何處理：

1、可將key設定過期時間，3min（3分鐘內，同一不存在key只需要查詢一次db即可）
2、若有合理場景，可不設定過期時間，有該key寫入資料時，更新key對應v即可。

 快取穿透解決方案二：

bloom過濾器

將所有可能存在的資料雜湊到一個足夠大的BitSet中，不存在的資料將會被攔截掉，從而避免了對底層儲存系統的查詢壓力

二、什麼是快取雪崩？

快取服務掛了，客戶端直接穿透快取，請求到資料庫裡面。資料庫負載非常高。甚至資料庫拖掛。

注：網上有說服重啟導致雪崩效應，筆者想了想應該不會。因為一般服務都叢集、低峰期重啟、且重啟後AOF 或 RDB持久化檔案會被優先載入，重新load重啟前快取資料到服務中。（意料之外的服務重啟除外）

雪崩解決方案：

1、保持快取層伺服器的高可用。監控、叢集、哨兵。當一個叢集裡面有一臺伺服器有問題，讓哨兵踢出去。

2、請求排隊處理，限流，避免db壓力突高

3、提前演練，快取層crash後，應用以及後端的負載情況以及可能出現的問題，對此做一些預案設定。

三、什麼是快取預熱？

提前批量Load快取資料：系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！

預熱思路：

1、直接寫個快取重新整理頁面，上線時手工操作下；

2、資料量不大，可以在專案啟動的時候自動進行載入；

3、定時重新整理快取；

四、快取熱點資料併發訪問？

A、B、C、D同時請求一個資源，不存在時都要去請求DB。

熱點資料重建優化方法： 

互斥鎖： 只允許一個請求重建快取。 其他請求等待快取重建執行完，重新從快取獲取資料即可。