Redis緩存系列

1、緩存雪崩

緩存雪崩咱們能夠簡單的理解爲：因爲原有緩存失效，新緩存未到期間(例如：咱們設置緩存時採用了相同的過時時間，在同一時刻出現大面積的緩存過時)，全部本來應該訪問緩存的請求都去查詢數據庫了，

而對數據庫CPU和內存形成巨大壓力，嚴重的會形成數據庫宕機。從而造成一系列連鎖反應，形成整個系統崩潰。

緩存正常從Redis中獲取，示意圖以下：

緩存失效瞬間示意圖以下：

緩存雪崩的解決方案：

（1）碰到這種狀況，通常併發量不是特別多的時候，使用最多的解決方案是加鎖排隊，僞代碼以下：

加鎖排隊只是爲了減輕數據庫的壓力，並無提升系統吞吐量。假設在高併發下，緩存重建期間key是鎖着的，這是過來1000個請求999個都在阻塞的。一樣會致使用戶等待超時，這是個治標不治本的方法！

注意：加鎖排隊的解決方式分佈式環境的併發問題，有可能還要解決分佈式鎖的問題；線程還會被阻塞，用戶體驗不好！所以，在真正的高併發場景下不多使用！

（2）給每個緩存數據增長相應的緩存標記，記錄緩存的是否失效，若是緩存標記失效，則更新數據緩存，實例僞代碼以下：

 

解釋說明：

一、緩存標記：記錄緩存數據是否過時，若是過時會觸發通知另外的線程在後臺去更新實際key的緩存；

二、緩存數據：它的過時時間比緩存標記的時間延長1倍，例：標記緩存時間30分鐘，數據緩存設置爲60分鐘。 這樣，當緩存標記key過時後，實際緩存還能把舊數據返回給調用端，直到另外的線程在後臺更新完成後，纔會返回新緩存。

關於緩存崩潰的解決方法，這裏提出了三種方案：使用鎖或隊列、設置過時標誌更新緩存、爲key設置不一樣的緩存失效時間，還有一各被稱爲「二級緩存」的解決方法，有興趣的讀者能夠自行研究。

2、緩存穿透

緩存穿透是指用戶查詢數據，在數據庫沒有，天然在緩存中也不會有。這樣就致使用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，而後返回空（至關於進行了兩次無用的查詢）。

這樣請求就繞過緩存直接查數據庫，這也是常常提的緩存命中率問題。

 緩存穿透解決方案：

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

（2）若是一個查詢返回的數據爲空（不論是數據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。

經過這個直接設置的默認值存放到緩存，這樣第二次到緩存中獲取就有值了，而不會繼續訪問數據庫，這種辦法最簡單粗暴！

把空結果也給緩存起來，這樣下次一樣的請求就能夠直接返回空了，便可以免當查詢的值爲空時引發的緩存穿透。同時也能夠單獨設置個緩存區域存儲空值，對要查詢的key進行預先校驗，而後再放行給後面的正常緩存處理邏輯。

 3、緩存預熱

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

 緩存預熱解決方案：

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

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

（3）定時刷新緩存；

4、緩存更新

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

（1）定時去清理過時的緩存；

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

二者各有優劣，第一種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較複雜！具體用哪一種方案，你們能夠根據本身的應用場景來權衡。

5、緩存降級

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

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

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

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

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

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

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