Redis中緩存雪崩和緩存穿透等問題的解決方案

這篇文章主要講解了“Redis中緩存雪崩和緩存穿透等問題的解決方案”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Redis中緩存雪崩和緩存穿透等問題的解決方案”吧！

緩存雪崩

緩存雪崩是指緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。

解決方案

1. 緩存數據的過期時間設置隨機，防止同一時間大量數據過期現象發生。

2. 一般并發量不是特別多的時候，使用最多的解決方案是加鎖排隊。

3. 給每一個緩存數據增加相應的緩存標記，記錄緩存的是否失效，如果緩存標記失效，則更新數據緩存。

   
   

緩存穿透

緩存穿透是指緩存和數據庫中都沒有的數據，導致所有的請求都落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。

解決方案

1. 接口層增加校驗，如用戶鑒權校驗，id做基礎校驗，id<=0的直接攔截；

2. 從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個id暴力攻擊

3. 采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力

   
   

附加

對于空間的利用到達了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。

Bitmap：典型的就是哈希表

缺點是，Bitmap對于每個元素只能記錄1bit信息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空間、時間來完成了。

布隆過濾器（推薦）

就是引入了k(k>1)k(k>1)個相互獨立的哈希函數，保證在給定的空間、誤判率下，完成元素判重的過程。

它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難。

Bloom-Filter算法的核心思想就是利用多個不同的Hash函數來解決“沖突”。

Hash存在一個沖突（碰撞）的問題，用同一個Hash得到的兩個URL的值有可能相同。為了減少沖突，我們可以多引入幾個Hash，如果通過其中的一個Hash值我們得出某元素不在集合中，那么該元素肯定不在集合中。只有在所有的Hash函數告訴我們該元素在集合中時，才能確定該元素存在于集合中。這便是Bloom-Filter的基本思想。

Bloom-Filter一般用于在大數據量的集合中判定某元素是否存在。

緩存擊穿

緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由于并發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力。和緩存雪崩不同的是，緩存擊穿指并發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。

解決方案

1. 設置熱點數據永遠不過期。

2. 加互斥鎖，互斥鎖

   
   

緩存預熱

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

解決方案

1. 直接寫個緩存刷新頁面，上線時手工操作一下；

2. 數據量不大，可以在項目啟動的時候自動進行加載；

3. 定時刷新緩存；

   
   

緩存降級

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

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

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

1. 一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而超時，可以自動降級；

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

3. 錯誤：比如可用率低于90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

4. 嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。

服務降級的目的，是為了防止Redis服務故障，導致數據庫跟著一起發生雪崩問題。因此，對于不重要的緩存數據，可以采取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去數據庫查詢，而是直接返回默認值給用戶。

熱點數據和冷數據

熱點數據，緩存才有價值

對于冷數據而言，大部分數據可能還沒有再次訪問到就已經被擠出內存，不僅占用內存，而且價值不大。頻繁修改的數據，看情況考慮使用緩存

對于熱點數據，比如我們的某IM產品，生日祝福模塊，當天的壽星列表，緩存以后可能讀取數十萬次。再舉個例子，某導航產品，我們將導航信息，緩存以后可能讀取數百萬次。

數據更新前至少讀取兩次，緩存才有意義。這個是最基本的策略，如果緩存還沒有起作用就失效了，那就沒有太大價值了。

那存不存在，修改頻率很高，但是又不得不考慮緩存的場景呢？有！比如，這個讀取接口對數據庫的壓力很大，但是又是熱點數據，這個時候就需要考慮通過緩存手段，減少數據庫的壓力，比如我們的某助手產品的，點贊數，收藏數，分享數等是非常典型的熱點數據，但是又不斷變化，此時就需要將數據同步保存到Redis緩存，減少數據庫壓力。

緩存熱點key

緩存中的一個Key(比如一個促銷商品)，在某個時間點過期的時候，恰好在這個時間點對這個Key有大量的并發請求過來，這些請求發現緩存過期一般都會從后端DB加載數據并回設到緩存，這個時候大并發的請求可能會瞬間把后端DB壓垮。

解決方案

對緩存查詢加鎖，如果KEY不存在，就加鎖，然后查DB入緩存，然后解鎖；其他進程如果發現有鎖就等待，然后等解鎖后返回數據或者進入DB查詢

感謝各位的閱讀，以上就是“Redis中緩存雪崩和緩存穿透等問題的解決方案”的內容了，經過本文的學習后，相信大家對Redis中緩存雪崩和緩存穿透等問題的解決方案這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！