作家
登錄

架構思維之緩存雪崩的災難復盤

作者: 來源: 2022-02-09 15:31:08 閱讀 我要評論

   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的請求,他們拿回了一個空值或者默認值,但是這局部的降級卻保證整個數據庫系統不被擁堵的請求擊穿。

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

  以上就是架構思維之緩存雪崩的災難復盤的詳細內容,更多關于緩存雪崩災難的資料請關注腳本之家其它相關文章!


  推薦閱讀

  蝴蝶優化算法及實現源碼

群智能算法學習筆記筆記內容和仿真代碼可能會不斷改動 如有不當之處,歡迎指正算法簡介蝴蝶優化算法(butterfly optimization algorithm, BOA)是Arora 等人于2019年提出的一種元啟發式智能算法。該算法受到了蝴蝶覓>>>詳細閱讀


本文標題:架構思維之緩存雪崩的災難復盤

地址:http://www.jychbg.com/kaifa/yejie/41187.html

關鍵詞: 探索發現

樂購科技部分新聞及文章轉載自互聯網,供讀者交流和學習,若有涉及作者版權等問題請及時與我們聯系,以便更正、刪除或按規定辦理。感謝所有提供資訊的網站,歡迎各類媒體與樂購科技進行文章共享合作。

網友點評
自媒體專欄

評論

熱度

精彩導讀
欄目ID=71的表不存在(操作類型=0)
免费观看人成视频在线播放