架構與思維：一次緩存雪崩的災難復盤

2021 年 12 月 10 日
筆記
cache, Redis, 架構與思維, 緩存, 緩存擊穿, 緩存穿透, 緩存雪崩

1 真實案例

雲辦公系統用戶實時信息查詢功能優化發佈之後，系統發生宕機事件（系統掛起，頁面無法加載）。

1.1 背景

我們IM原有的一個功能，當鼠標移動到用戶頭像的時候，會顯示出用戶的基本信息。信息比較簡單，只包含簡單的用戶名、昵稱、性別、郵箱、電話等基本數據，

這是一個典型的數據查詢，大概過程如下左側，訪問用戶基本信息的時候會先去Redis中查一下，如果不存在，就把大約2W左右的用戶數據一次性取出來，保存在Redis中，因為用戶基本信息在同一張表上，用戶信息表的數據量也很少，所以一直也沒什麼問題。

過程如下圖左側所示。

後續對功能做了優化，原有採集的信息除了用戶的基本信息之外，還採集了教育經歷、工作經歷、所獲勳章等。

這些信息存儲在不同的表裏面，所以採集過程是一個複雜的聯表查詢，特別是有些基礎表數據量比較大，執行效率也是比較慢的。

如果把所有用戶全部取出來並存儲在一個Redis節點中，明顯已經不適用，一個是批量查詢導致數據庫執行效率慢，一個是Redis單節點數據太大。

所以開發同學做了下優化，每次只取單個用戶的綜合信息存在Redis中，一個用戶建一個緩存，如上圖右側所示。

1.2 問題處理

這種做法看着沒啥問題，當晚發佈後，在第二天的上午10點~11點就發生了系統瓶頸卡頓，最後掛起的情況，數據庫的內存、CPU全部飆上去了。

第一時間的處理方法是降級，程序回滾到之前只提供基本信息的階段，其他的前端默認顯示空信息。接着就是對問題進行分析了，後確認原因是產生了緩存雪崩了。

新發佈的系統，緩存池是空的，在早上10點高峰期的時候，大量的人員到IM上進行訪問，系統開始初次建立每個人的緩存信息，大量的請求查詢不到緩存，直接透過緩存池投向數據庫，造成瞬時DB請求量井噴。這是典型的緩存雪崩了。

同時因為，失效時間相近（8小時失效），所以也有潛在的緩存雪崩。

應急處理方案：適當處理緩存的機制，採用布隆過濾器、空初始值、隨機緩存失效時間方式來預防緩存擊穿和緩存雪崩的產生。

最終解決方案：改回原來緩存全公司員工信息的方式，根據執行計劃和SlowLog，優化獲取員工信息的SQL腳本，去掉不需要的字段和無意義的連接。

2 緩存雪崩

2.1 概念

緩存雪崩是指大量的key設置了相同的過期時間，導致在緩存在同一時刻全部失效，造成瞬時DB請求量大、壓力驟增，引起雪崩。

上面的哪個問題，初次訪問的數據都是未建立緩存的，跟同時失效的情況一樣，當峰值期到來的時候，會大量的請求查詢不到緩存，直接透過緩存池投向數據庫，造成瞬時DB請求量井噴。

2.2 解決方案分析

2.2.1 緩存集群+數據庫集群

在系統容量設計的時候，應該能夠預見後期會有大量的請求，所以在發生雪崩前對緩存集群實現高可用，如果是使用 Redis，可以使用主從+哨兵，Redis Cluster 來避免 Redis 全盤崩潰的情況。

同樣的，也需要對數據庫進行高可用保障，因為透過緩存之後，真正考驗的是數據庫的抗壓能力。所以 1主N從甚至數據庫集群是我們需要重點去考慮的。

2.2.2 適當的限流、降級

可以使用 Hystrix進行限流 + 降級，比如像上面那種情況，一下子來了1W個請求，不是當前系統的吞吐能力能夠承受的，假設單秒TPS的能力只能是 5000個，那麼剩餘的 5000 請求就可以走限流邏輯。

可以設置一些默認值，然後調用我們自己降級邏輯去FallBack，保護最後的 MySQL 不會被大量的請求掛起。除了Hystrix之外，阿里的Sentinel 和 Google的RateLimiter 都是不錯的選擇。

Sentinel 漏桶算法

RateLimiter 令牌桶算法

另外可以考慮使用用本地緩存來進行緩衝，在 Redis Cluster 不可用的時候，不至於全線崩潰。

2.2.3 隨機過期時間

可以給緩存設置過期時間時加上一個隨機值時間，使得每個key的過期時間分佈開來，不會集中在同一時刻失效。

隨機值我們團隊的做法是：n * 3/4 + n * random() 。所以，比如你原本計劃對一個緩存建立的過期時間為8小時，那就是6小時 + 0~2小時的隨機值。

這樣保證了均勻分佈在 6~8小時之間。如圖：

2.2.4 緩存預熱

類似上面的那個案例，並不是還沒過期，而是新功能發佈，壓根還沒建設過緩存，所以可以在峰值期之前先做好部分緩存，避免瞬時壓力太大。

所以如果10點是峰值期，那麼可以預先在8~10點期間，可以逐漸的把大部分緩存建立起來。如圖：

3 緩存穿透

3.1 概念

緩存穿透是指訪問一個不存在的key，緩存不起作用，請求會穿透到DB，流量井噴時會導致DB掛掉。

比如我們查詢用戶的信息，程序會根據用戶的編號去緩存中檢索，如果找不到，再到數據庫中搜索。如果你給了一個不存在的編號：XXXXXXXX，那麼每次都比對不到，就透過緩存進入數據庫。

這樣風險很大，如果因為某些原因導致大量不存在的編號被查詢，甚至被惡意偽造編號進行攻擊，那將是災難。

3.2 解決方案分析

3.2.1 緩存空值

發生穿透的原因是緩存中沒有存儲這些空數據的key，或者壓根這個數據的key是不會存在的，從而導致每次查詢都進入數據庫中。

我們就可以將這些key的值設置為null，並寫到緩存池中。後面再出現查詢這個key 的請求的時候，直接返回null，這樣就在緩存池中就被判斷返回了，壓力在緩存層中，不會轉移到數據庫上。

3.2.2 BloomFilter

我們稱作布隆過濾器，BloomFilter 類似於一個hbase set 用來判斷某個元素（key）是否存在於某個集合中。

這種方式在大數據場景應用比較多，比如 Hbase 中使用它去判斷數據是否在磁盤上。還有在爬蟲場景判斷url 是否已經被爬取過。

這種方案可以加在第一種方案中，在緩存之前在加一層 BloomFilter ，把存在的key記錄在BloomFilter中，在查詢的時候先去 BloomFilter 去查詢 key 是否存在，如果不存在就直接返回，存在再走查緩存，投入數據庫去查詢，這樣減輕了數據庫的壓力。

流程圖如下：

3.2.3 兩種方案的選擇判斷

前面說過，可能會存在一些惡意攻擊，偽造出大量不存在的key ，這種情況下如果我們如果採用緩存空值的辦法，就會產生大量不存在key的null數據。顯然是不合適的，這時我們完全可以使用第二種方案進行過濾掉這些key。

所以，判斷的依據是：

針對key非常多、請求重複率比較低的數據，我們就沒有必要進行緩存，使用 BloomFilter 直接過濾掉。

而對於空數據的key有限的，重複率比較高的，我們則可以採用緩存空值的辦法進行處理。

4 緩存擊穿

4.1 概念

一個存在的key，在緩存過期的一刻，同時有大量的請求，這些請求都會擊穿到DB，造成瞬時DB請求量大、壓力驟增。（注意跟上面兩種的區別）

4.2 解決方案

4.2.1 鎖的方式

分佈式鎖場景，在訪問key之前，採用SETNX（set if not exists）來設置另一個短期key來鎖住當前key的訪問，訪問結束再刪除該短期key。

這種現象是多個線程同時去查詢數據庫的這條數據，那麼我們可以在第一個查詢數據的請求上使用一個互斥鎖來鎖住它。

其他的線程走到這一步拿不到鎖就等着，等第一個線程查詢到了數據，然後做緩存。後面的線程進來發現已經有緩存了，就直接走緩存。

鎖不好的地方就是在其他線程在拿不到鎖的時候就等待，這個會造成系統整體吞吐量降低，用戶體驗度也不好。

4.2.2 空初始值

這是一種短暫降級的方式：

如果一個緩存失效的時候，有無數個請求狂奔而來，而第一個請求從進入緩存池，判空，再到數據庫檢索，再查詢出結果並返回設置緩存的這個過程里，緩存是不存在的。

這個就很危險，超高並發下這個短暫的過程足已讓千千萬萬請求投向數據庫。更別提這可能是個慢查詢，整個過程可能長達2s以上，那對數據庫是一種非常大的傷害。

業內有一種做法叫做空初始值，短暫的局部降級來保證整個數據庫系統不被擊穿。大概流程如下：

可以看出，整個過程中我們犧牲了A、B、C、D的請求，他們拿回了一個空值或者默認值，但是這局部的降級卻保證整個數據庫系統不被擁堵的請求擊穿。

這也是我面試中最喜歡問候選人的緩存類問題。

Tags: cache Redis 架構與思維緩存緩存擊穿緩存穿透緩存雪崩