1、緩存雪崩
發生場景：當Redis服務器重啟或者大量緩存在同一時期失效時,此時大量的流量會全部沖擊到數據庫上面,數據庫有可能會因為承受不住而宕機
解決辦法：
1）隨機均勻設置失效時間
2）設置過期標志更新緩存
3）並發量不是特別多的時候，使用最多的解決方案是加鎖排隊
2、緩存穿透
發生場景：是指查詢一個數據庫一定不存在的數據。正常的使用緩存流程大致是，數據查詢先進行緩存查詢，如果key不存在或者key已經過期，再對數據庫進行查詢，並把查詢到的對象，放進緩存。如果數據庫查詢對象為空，則不放進緩存。此時，若攻擊者抓住這個漏洞不斷請求數據庫，就會對數據庫造成壓力，甚至壓垮數據庫。
解決辦法：采用緩存空值的方式，也就是從數據庫查詢的對象為空，也放入緩存，只是設定的緩存過期時間較短，比如設置為60秒。
3、緩存預熱
是一種機制, 就是系統上線后，提前將相關的緩存數據直接加載到緩存系統。避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題。
4、緩存更新
是一種機制,怎么樣保證緩存中的key是實時有效的,以及及時的更新數據資源
解決辦法：
1）緩存服務器自帶的緩存失效策略
2）自定義：定時去清理過期的緩存；當用戶請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統得到新數據並更新緩存。
5、緩存降級
發生場景：當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。
解決辦法：
在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設置預案：
（1）一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而超時，可以自動降級；
（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，並發送告警；
（3）錯誤：比如可用率低於90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
（4）嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。