Redis系列教程(三)：如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题
Java相關的面試都會問到緩存的問題：史上最全Redis面試49題（含答案）:哨兵+復制+事務+集群+持久化等，除此之外還會問到緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等不常見的問題，但卻是非常重要的問題，今天談談這個話題。
基本看完這兩篇，可以對redis有一個比較全面的初步了解，后續我再補充redis相關的實戰篇，總結為一個redis系列。
緩存雪崩
數據未加載到緩存中，或者緩存同一時間大面積的失效，從而導致所有請求都去查數據庫，導致數據庫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的client同時set
key引起的并發問題。其實redis自身就是單線程操作，多個client并發操作，按照先到先執行的原則，先到的先執行，其余的阻塞。當然，另外的解決方案是把redis.set操作放在隊列中使其串行化，必須的一個一個執行。
緩存預熱
緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。
這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
解決思路：
1、直接寫個緩存刷新頁面，上線時手工操作下；
2、數據量不大，可以在項目啟動的時候自動進行加載；
目的就是在系統上線前，將數據加載到緩存中。
以上就是緩存雪崩、預熱、降級等的介紹，更多整體從服務器雪崩的角度，具體可以參考：阿里P8架構師談：什么是緩存雪崩？服務器雪崩的場景與解決方案
你可能也喜歡:
總結
以上是生活随笔為你收集整理的Redis系列教程(三)：如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿里P8架构师谈：从单体架构、到SOA、
- 下一篇： 阿里P8架构师谈：多线程、架构、异步消息