快看，我們的分散式緩存就是這樣把註冊中心搞崩塌的！
作者 | 王曄倞
責編 | 郭 芮
寫公眾號兩年以來，每當有機會寫故障類主題的時候，我都會在開始前靜靜地望著顯示器很久，經過多次煎熬和掙扎之後才敢提起筆來。
為什麼呢？因為這樣的話題很容易招來吐槽，比如 「說了半天，不就是配置沒配好嗎？」，或者 「這代碼是豬寫的嗎？你們團隊有懂性能測試的同學嗎？」，這樣的評論略帶挑釁，而且充滿了鄙視之意。
不過我覺得，在技術的世界裡，多數情況都是客觀場景決定了主觀結果，而主觀結果又反映了客觀場景，把場景與結果串起來，用自己的方式寫下來，傳播出去，與有相同經歷的同學聊上一聊，也未嘗不是一件好事。
上個月，我們的系統因註冊中心崩塌而引發的一場事故，本是一件稀鬆平常的事件，可我們猜中了開始卻沒料到原因，始作俑者竟是已在產線運行多年的某分散式緩存系統。
這到底是怎麼一回事呢？
先來回顧一下故障過程
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混用。
說到這裡，這個故事也該結束了。
講在最後
看完這個故事，一些愛好懟人的小夥伴也許會忍不住發問：你們自己設計的架構，你們自己編寫的代碼，難道不知道其中的邏輯嗎？這麼低級的錯誤，居然還有臉拿出來說？
那可未必，對每個技術團隊而言，核心成員的離職與業務形態的變化，都或多或少會引發技術團隊對現有系統形成 「知其然而，卻不知其所以然」 的情況，雖說每個團隊都在想方設法進行避免，但想完全杜絕，絕非易事。
作為技術管理者，具備良好的心態，把每次故障都看成是一次蟬變的過程，從中得到總結與經驗，並加以傳承，今後不再就犯，那就是好樣的。
不過，萬一哪天失手，給系統來了個徹底癱瘓，該怎麼辦呢？
祝大家一切順利吧。
作者：王曄倞，18年IT從業經驗，現任職好買財富平台架構部技術總監，負責好買中間件及平台化的研發及運營，團隊管理和實施重大技術決策。曾任大智慧測試總監，在2年內帶領團隊自研了「大智慧雲測試平台」，通過平台化將金融數據服務業務從瀑布式逐漸轉型為DevOps。
聲明：本文為作者投稿，版權歸作者個人所有。
熱 文推 薦
TAG:CSDN |