Redis系列七：redis緩存雪崩、緩存擊穿、緩存預熱、緩存更新、緩存降級

1、緩存雪崩

一、概念

緩存同一時間實效（因爲設置相同的緩存時間），同時訪問數據庫，從而對數據庫cpu和內存形成巨大壓力，嚴重的會致使數據庫宕機，從而造成一系列連鎖反應，形成整個系統崩潰。

二、解決方案

A、使用鎖或隊列訪問數據庫（非高併發場景，否則嚴重阻塞）

B、設置過時標誌更新緩存（數據過時時長是標誌時長的兩倍，表示過時，返回舊數據給調用端，異步加載數據到緩存）

C、爲key設置不一樣的緩存失效時間

D、「二級緩存」，待研究

2、緩存穿透

一、概念

用戶查詢數據，在數據庫沒有，天然在緩存中也沒有，這樣就致使用戶查詢的時候，每次都要去數據庫再查詢一遍，而後返回空（至關於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查詢數據庫，這也就是常常提的緩存命中率問題。

二、解決方案

A、採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的bitmap中，一個必定不存在的數據會被這個bitmap攔截，從而避免了對底層存儲系統的查詢壓力。（多個哈希函數）

B、若一個查詢返回的數據爲空（不論是數據不存在仍是系統故障），仍然吧這個空結果進行緩存，但它的過時時間會很短，最長不超過5分鐘，經過這個直接設置的默認值存放到緩存，這樣第二次到緩存中獲取就有值了，而不會繼續訪問數據庫，這種辦法簡單粗暴。

3、緩存預熱

一、概念

系統上線後，提早將先關的緩存數直接加載到緩存系統，避免在用戶請求的時候，先查詢數據庫，而後再講數據緩存的問題。用戶直接查詢事先被預熱的緩存數據。

二、解決方案

A、直接寫個緩存刷新頁面，上線時手工操做下；

B、數據量不大，能夠在項目啓動的時候自動進行加載；

C、定時刷新緩存。

 

4、緩存更新

除緩存服務器自帶的緩存失效策略外（Redis默認的有6中策略可供選擇），咱們還能夠根據具體的業務場景進行自定義的緩存失效，常見策略以下：

A、定時清理過時的緩存；

B、當有用戶請求過來時，再判斷這個請求所用到的緩存是否過時，過時的話就去底層系統獲得新數據並更新緩存。

 

兩種方案的優缺點：

第一種缺點是維護大量緩存的key比較麻煩，第二種的缺點是每次你用戶請求過來都要判斷緩存失效，邏輯相對複雜！

 

5、緩存降級

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然須要保證服務仍是可用的，即便是有損服務。系統能夠根據一些關鍵數據進行自動降級，也能夠配置開關實現人工降級。

 

降級的最終目的是保證核心服務可用，即便是有損的。並且有些服務是沒法降級的（如加入購物車、結算）。

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

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

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

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

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