緩存雪崩
數據未加載到高速緩存中，或者高速緩存同時在較大區域中失效，這將導致所有請求都去查找數據庫，從而導致數據庫CPU和內存負載過高，甚至會出現宕機。
比如雪崩的一個簡單過程：
1、redis集群大面積出現故障
2、緩存失效了，但是依舊會有大量的請求訪問緩存服務redis
3、redis大量失效後，這個時候大量的請求轉向到mysql數據庫
4、mysql的調用量暴增了，一下子就扛不住了，甚至直接宕機
5、由於大量的應用服務依賴mysql和redis的服務，這個時候很快會演變成各服務器集群的雪崩，最後網站完全崩潰
如何預防緩存雪崩
1.緩存的高可用性
高速緩存層設計為高可用，以防止大面積的高速緩存故障。 即使是個別節點、個別機器甚至機房宕掉，仍然可以提供服務。 例如，Redis Sentinel和Redis Cluster已實現高可用性。
2.緩存降級
可以使用諸如ehcache（暫時支持）之類的本地緩存，但主要是限制對源服務的訪問，資源隔離（熔斷）和降級。 當流量高峰和服務出現問題時，仍然需要確保服務仍然可用。 系統可以根據一些關鍵數據自動降級，也可以配置開關實現人工降級，在這一塊會涉及到運維的配合。
降級的最終目的是保證核心服務可用，即使是有損的。
比如推薦服務中，很多都是個性化的需求，假如個性化需求不能提供服務了，可以降級補充熱點數據，不至於造成前端頁面是個大空白。
例如，在推薦服務中，很多都是個性化的需求， 如果個性化需求無法提供服務了，那就可以降級和補充熱門數據，這樣子就不會造成前端頁面出現空白頁面。
在降級之前，需要對系統進行梳理，例如：哪些企業是核心（必須保證），哪些企業可以暫時忍受不提供服務（使用靜態頁面替換）等，以及配合服務器核心指標，來後設置整體預案，比如：
（1）一般：例如，某些服務可能由於網絡抖動或服務正在上線而超時，這些服務可以自動降級；
（2）警告：某些服務的成功率會在一段時間（例如95到100％之間）之間波動，可以自動降級或手動降級併發送告警；
（3）錯誤：例如，如果可用性低於90％，或者數據庫連接池被打爆了，或者訪問數量突然增加到系統可以承受的最大閾值，則可以根據情況自動降級或手動降級；
（4）嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。
3.Redis備份和快速預熱
1)Redis數據備份和恢復
2)快速緩存預熱
4.提前演練
最後，建議在項目上線之前，演練緩存層宕掉之後，應用程序和後端負載情況以及可能出現的問題，對高可用提前預演，並提前發現問題。
緩存穿透
緩存穿透是指查詢不存在的數據。 例如：緩存中的redis未命中，您需要從mysql數據庫中查詢，如果找不到數據，則不會將其寫入緩存中。 這將導致每次請求該不存在的數據都將查詢到數據庫，從而導致緩存穿透。
解決思路：
如果查詢數據庫也為空，則直接為緩存設置默認值，以便第二次從緩存中獲取該值時，它將具有該值，就不會繼續訪問數據庫。 設置一個過期時間或在有值時替換高速緩存中的值。
可以為key設置一些格式規則，然後在查詢之前過濾掉不符合規則的key。
緩存併發
併發是指由多個Redis客戶端同時set key引起的併發問題。 實際上，redis本身是一個單線程操作。 多個客戶端同時運行，按照先到先執行的原則，先到的先執行，其餘的阻塞。 當然，另一種解決方案是將redis.set操作放在隊列中以對其進行序列化，該操作必須一個接一個地執行。
緩存預熱
緩存預熱是在系統上線後將相關的緩存數據直接加載到緩存系統中。
這樣就可以避免在用戶請求的時候，先查詢數據庫，然後在用戶請求時緩存數據的問題！ 用戶直接查詢預熱的緩存數據！
解決思路：
1、直接寫個緩存刷新頁面，上線時手工操作一下；
2、數據量不大時，可以在項目啟動的時候自動進行加載；
