架構與思維:一次快取雪崩的災難覆盤

翁智華發表於2021-12-10

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的請求,他們拿回了一個空值或者預設值,但是這區域性的降級卻保證整個資料庫系統不被擁堵的請求擊穿。

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

相關文章