Redis之緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級

一、緩存雪崩

發生場景：當Redis服務器重啓或者大量緩存在同一時期失效時,此時大量的流量會所有衝擊到數據庫上面,數據庫有可能會由於承受不住而宕機

　　解決辦法：

　　　　1）隨機均勻設置失效時間

　　　　2）設置過時標誌更新緩存

　　　　3）併發量不是特別多的時候，使用最多的解決方案是加鎖排隊

二、緩存穿透

　　發生場景：是指查詢一個數據庫必定不存在的數據。正常的使用緩存流程大體是，數據查詢先進行緩存查詢，若是key不存在或者key已通過期，再對數據庫進行查詢，並把查詢到的對象，放進緩存。若是數據庫查詢對象爲空，則不放進緩存。此時，若攻擊者抓住這個漏洞不斷請求數據庫，就會對數據庫形成壓力，甚至壓垮數據庫。

　　解決辦法：採用緩存空值的方式，也就是從數據庫查詢的對象爲空，也放入緩存，只是設定的緩存過時時間較短，好比設置爲60秒。

三、緩存預熱

是一種機制, 就是系統上線後，提早將相關的緩存數據直接加載到緩存系統。避免在用戶請求的時候，先查詢數據庫，而後再將數據緩存的問題。

四、緩存更新

　是一種機制,怎麼樣保證緩存中的key是實時有效的,以及及時的更新數據資源

　　解決辦法：

　　　　1）緩存服務器自帶的緩存失效策略

　　　　2）自定義：定時去清理過時的緩存；當用戶請求過來時，再判斷這個請求所用到的緩存是否過時，過時的話就去底層系統獲得新數據並更新緩存。

五、緩存降級

發生場景：當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然須要保證服務仍是可用的，即便是有損服務。系統能夠根據一些關鍵數據進行自動降級，也能夠配置開關實現人工降級。降級的最終目的是保證核心服務可用，即便是有損的。並且有些服務是沒法降級的（如加入購物車、結算）。

　　解決辦法：

　　　　在進行降級以前要對系統進行梳理，看看系統是否是能夠丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；好比能夠參考日誌級別設置預案：

　　　　（1）通常：好比有些服務偶爾由於網絡抖動或者服務正在上線而超時，能夠自動降級；

　　　　（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），能夠自動降級或人工降級，併發送告警；

　　　　（3）錯誤：好比可用率低於90%，或者數據庫鏈接池被打爆了，或者訪問量忽然猛增到系統能承受的最大閥值，此時能夠根據狀況自動降級或者人工降級；

　　　　（4）嚴重錯誤：好比由於特殊緣由數據錯誤了，此時須要緊急人工降級。