[[399021]]

本文轉(zhuǎn)載自微信公眾號「六脈神劍的程序人生」，作者六脈神劍小六六。轉(zhuǎn)載本文請聯(lián)系六脈神劍的程序人生公眾號。

前言

文本已收錄至我的GitHub倉庫，歡迎Star：https://github.com/bin392328206/six-finger 種一棵樹最好的時間是十年前，其次是現(xiàn)在

大家好，我是小六六，目前在一線互聯(lián)網(wǎng)公司負(fù)責(zé)年營收過百億的支付中臺項目，感謝大家的支持，今天我們來看看 線上服務(wù)CPU飆升的問題

絮叨

• 功能開發(fā)完成僅僅是項目周期中的第一步，一個完美的項目是在運行期體現(xiàn)的
• 今天我們就來看看筆者之前遇到的一個問題CPU飆升的問題。代碼層面從功能上看沒有任何問題但是投入使用后卻讓我頭大

問題描述

系統(tǒng)上點擊數(shù)據(jù)錄入功能在全局監(jiān)控中會收到相關(guān)消息的通知。此時服務(wù)器CPU飆升300%

問題定位

• 首先我們先梳理下Websocket的數(shù)據(jù)發(fā)送的簡單原理示意圖。往往定位問題得清楚我們的邏輯是什么
• 當(dāng)一個客戶端啟動時除了和Websocket建立連接之外，我們還需要向Websocket服務(wù)注冊當(dāng)前客戶端需要哪些接口的實時數(shù)據(jù)
• 我在代碼內(nèi)部是通過一個Map來存儲這些接口簽名信息的。然后客戶注冊時候?qū)⑦@些接口和客戶端綁定在一起
• 當(dāng)我們監(jiān)聽程序堅挺到數(shù)據(jù)變動就會對綁定到相關(guān)接口的客戶端發(fā)送最新數(shù)據(jù)

業(yè)務(wù)定位

業(yè)務(wù)上很好定位，問題就是出現(xiàn)在我們的監(jiān)聽程序中。當(dāng)監(jiān)聽到數(shù)據(jù)給websocket客戶端發(fā)送訂閱的最新變動接口時就會出現(xiàn)CPU飆升。持續(xù)時間還很長，稍等一會就會降下來

這很明顯是我們推送消息的時候出現(xiàn)了問題

隔離業(yè)務(wù)看本質(zhì)

• 作為一個合格的程序員呢，必須擺脫業(yè)務(wù)才能有所收獲 。業(yè)務(wù)是我們代碼的外殼所有的問題基本上都是我們本質(zhì)的問題。我們線上使用用戶1W內(nèi)。在這種的并發(fā)場景下應(yīng)該是不會出問題的。現(xiàn)在出了問題肯定我們的程序邏輯有缺陷

• 上面是我們的發(fā)送消息的代碼。代碼也很簡單。先獲取所有符合發(fā)送條件的客戶端 。然后通過客戶端內(nèi)部提供的sendMessage方法進行推送。
• 但是這個時候的message 是我們的接口信息。在內(nèi)部會基于客戶端保存的方法簽名進行反射調(diào)用從而獲取最新數(shù)據(jù)。在推送給客戶端的
• 在上面的代碼中核心的是WebsocketManager.messageParse 。這段是獲取消息然后發(fā)送。里面獲取消息是基于resultful格式解析的

• 這個方法內(nèi)部我們有內(nèi)置了我們的四種解析方式。這里我們只需要關(guān)心RequestMappingMessageParseHandlerImpl 這個協(xié)議。

• 關(guān)于我們內(nèi)部的協(xié)議這里也不需要太在意。這是我們自己的一個設(shè)計。根據(jù)上面的圖示我們也能看的出來里面RequestMappingMessageParseHandlerImpl 是核心

產(chǎn)生原因

• 上面我們簡單的梳理了下代碼的邏輯。
• 仔細(xì)分析下我們是遍歷所有客戶端然后在反射調(diào)用接口數(shù)據(jù)進行返回的。實際上在消息推送時我們沒必要在每個客戶端內(nèi)部調(diào)用數(shù)據(jù)。我們完全可以先調(diào)用數(shù)據(jù)然后在遍歷客戶端進行發(fā)送。
• 這也是導(dǎo)致CPU過高的問題。我們1W個用戶同事在線的可能有5000+ 。那么我們需要5000次以上的反射著肯定是吃不消的。這也是為什么本文開頭說功能正常不代表業(yè)務(wù)正常。

解決方案

• 這就是量變引起質(zhì)變。在多客戶的情況下我們的設(shè)計弊端就暴露出來。這里也是筆者自己給自己挖坑。既然找到問題我們就好解決了。下面我們對代碼做了一下改動

• 我將數(shù)據(jù)緩存起來。因為在同一批次推送時本來也應(yīng)該保證數(shù)據(jù)一致性。而且我們系統(tǒng)對數(shù)據(jù)實時性也是可以接受一定時間延遲的。我在這里又加上緩存這樣就解決了我們循環(huán)的問題
• 經(jīng)過測試本次改動在CPU上大概優(yōu)化了100倍。

總結(jié)

• 功能開發(fā)完成僅僅代表功能的實驗沒有問題
• 單用戶和多用戶完全是兩種不同的用戶形態(tài)。我們功能設(shè)計初期就應(yīng)該盡量考慮數(shù)據(jù)量的問題
• 唯一做的好的地方是我通過責(zé)任鏈模式將數(shù)據(jù)解析隔離出來。否則這樣的問題定位將會更加麻煩