1. 程式人生 > >快看,我們的分散式快取就是這樣把註冊中心搞崩塌的

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的

寫公眾號兩年以來,每當有機會寫故障類主題的時候,我都會在開始前靜靜地望著顯示器很久,經過多次煎熬和掙扎之後才敢提起筆來。

為什麼呢?因為這樣的話題很容易招來吐槽,比如 “說了半天,不就是配置沒配好嗎?”,或者 “這程式碼是豬寫的嗎?你們團隊有懂效能測試的同學嗎?”,這樣的評論略帶挑釁,而且充滿了鄙視之意。

不過我覺得,在技術的世界裡,多數情況都是客觀場景決定了主觀結果,而主觀結果又反映了客觀場景,把場景與結果串起來,用自己的方式寫下來,傳播出去,與有相同經歷的同學聊上一聊,也未嘗不是一件好事。

上個月,我們的系統因註冊中心崩塌而引發的一場事故,本是一件稀鬆平常的事件,可我們猜中了開始卻沒料到原因,始作俑者竟是已在產線執行多年的某分散式快取系統。

這到底是怎麼一回事呢?

先來回顧一下故障過程

11月,某交易日的上午10點左右。

在中介軟體監控系統沒有觸發任何報警的情況下,某應用團隊負責人突然跑過來說:“怎麼快取響應怎麼慢?你們在幹什麼事嗎?”

由於此正在交易盤中,中介軟體運維團隊瞬間炸鍋,緊急查看了一系列監控資料,先是通過Zabbix查看了如CPU、記憶體、網路及磁碟等基礎預警,一切正常,再檢視服務健康狀況,經過一圈折騰之後,也沒發現任何疑點。

懵圈了,沒道理啊。

10點30分,收到一通報警資訊,內容為“ZK叢集中的某一個節點故障,埠不通,不能獲取Node資訊,請迅速處理!”。

這簡單,ZK服務埠不通,重啟,立即恢復。

10點40分,ZK叢集全部癱瘓,無法獲取Node資料,由於應用系統的Dubbo服務與分散式快取使用的是同一套ZK叢集,而且在此期間應用未重啟過,因此應用服務自身暫時未受到影響。

沒道理啊,無論應用側還是快取側,近一個月以來都沒有釋出過版本,而且分散式快取除了在ZK中存一些節點相關資訊之外,基本對ZK無依賴。

10點50分,ZK叢集全部重啟,10分鐘後,再次癱瘓。

神奇了,到底哪裡出了問題呢?

10點55分,ZK叢集全部重啟,1分鐘後,發現Node Count達到近22W+,再次崩潰。

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

10點58分,通過增加監控指令碼,查明Node源頭來自分散式快取系統的本地快取服務。

11點00分,通過控制檯關閉本地快取服務後,ZK叢集第三次重啟,通過指令碼刪除本地化快取所產生的大量Node資訊。

11點05分,產線ZK叢集全部恢復,無異常。

一場風波雖說過去了,但每個人的臉上流露出茫然的表情。邪了門了,這本地快取為什麼能把註冊中心搞崩塌?都上線一年多了,之前為什麼不出問題?為什麼偏偏今天出事?

一堆的問號,充斥著每個人的大腦。

我們本地快取的工作機制

在這裡,我先通過系統流程示意圖的方式,簡要地說明下我們本地快取系統的一些核心工作機制。

非本地快取的工作機制

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

本地快取的工作機制 - KEY預載入/更新

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

本地快取的工作機制 - Set/Delete操作

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

本地快取的工作機制 - Get操作

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

順帶提一句,由於歷史性與資源緊缺的原因,我們部分快取系統與應用系統的ZK叢集是混用的,正因如此,給本次事故埋下了隱患。

ZK叢集是怎樣被搞掛的呢?

說到這裡,相信對中介軟體有一定了解的人基本能猜出本事件的全貌。

簡單來說,就是在上線初期,由於流量小,應用系統接入量小,我們本地快取的訊息通知是利用ZK來實現的,而且還用到了廣播。但隨著流量的增加與應用系統接入量的增多,訊息傳送量成倍增長,最終達到承載能力的上限,ZK叢集崩潰。

的確,原因基本猜對了,但訊息傳送量為什麼會成倍的增長呢?

根據本地快取的工作機制,我們一般會在裡面存些什麼呢?

更新頻率較低,但訪問卻很頻繁,比如系統引數或業務引數。

單個Key/Value較大,網路消耗比較大,效能下降明顯。

服務端資源匱乏或不穩定(如I/O),但對穩定性要求極高。

懵圈了,就放些引數類資訊,而且更新頻率極低,這樣就把五個節點的ZK叢集發爆了?

為了找到真相,我們立即進行了程式碼走讀,最終發現了蹊蹺。

快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

根據設計,在 “本地快取的工作機制 - Set/Delete操作” 的工作機制中,當一個Key完成服務端快取操作後,如果沒有被加到本地快取規則列表中的KEY,是不可能被觸發訊息通知的,但這裡明視訊記憶體在BUG,導致把所有的KEY都發到了ZK中。

這樣就很好理解了,雖然應用系統近期沒有釋出版本,但卻通過快取控制檯,悄悄地把分散式鎖加到了這套快取分片中,所以交易一開盤,只需幾十分鐘,立馬打爆。

另外,除了發現BUG之外,通過事後測試驗證,我們還得出了以下幾點結論:

  • 利用ZK進行訊息同步,ZK本身的負載能力較弱,是否切換到MQ?
  • 監控手段的單一,監控的薄弱;
  • 系統部署結構不合理,基礎架構的ZK不應該與應用的ZK混用。
快看,我們的分散式快取就是這樣把註冊中心搞崩塌的!

 

說到這裡,這個故事也該結束了。

講在最後

看完這個故事,一些愛好懟人的小夥伴也許會忍不住發問:你們自己設計的架構,你們自己編寫的程式碼,難道不知道其中的邏輯嗎?這麼低階的錯誤,居然還有臉拿出來說?

那可未必,對每個技術團隊而言,核心成員的離職與業務形態的變化,都或多或少會引發技術團隊對現有系統形成 “知其然而,卻不知其所以然” 的情況,雖說每個團隊都在想方設法進行避免,但想完全杜絕,絕非易事。

作為技術管理者,具備良好的心態,把每次故障都看成是一次蟬變的過程,從中得到總結與經驗,並加以傳承,今後不再就犯,那就是好樣的。

不過,萬一哪天失手,給系統來了個徹底癱瘓,該怎麼辦呢?

祝大家一切順利吧。