說到“多協(xié)議網(wǎng)絡(luò)庫設(shè)計(jì)”這五個(gè)字很多同學(xué)第一反應(yīng)是又有人要造輪子了。但真當(dāng)你在生產(chǎn)環(huán)境摸過一把之后才會(huì)理解為什么要把多種協(xié)議揉進(jìn)一個(gè)庫而不是每接一種新客戶端就新起一個(gè)項(xiàng)目。我之前在某物聯(lián)網(wǎng)平臺(tái)做過一版統(tǒng)一接入網(wǎng)關(guān)業(yè)務(wù)側(cè)要同時(shí)接私有二進(jìn)制協(xié)議、MQTT、WebSocket和標(biāo)準(zhǔn)HTTP前前后后折騰了大半年最后沉淀下來的核心不是這些協(xié)議各自怎么實(shí)現(xiàn)而是怎么讓它們共用一個(gè)連接模型、一套事件循環(huán)和一套背壓機(jī)制。這篇文章就把我踩過的坑和最終落地的設(shè)計(jì)思路完整捋一遍。適合正在做網(wǎng)絡(luò)中間件、網(wǎng)關(guān)SDK、即時(shí)通訊服務(wù)端的同學(xué)參考也包括那些業(yè)務(wù)里被迫要接多種協(xié)議、被半包粘包和連接風(fēng)暴折磨過的人。我會(huì)直接從需求拆解講到架構(gòu)分層再落到狀態(tài)機(jī)、緩沖區(qū)、定時(shí)器這些關(guān)鍵細(xì)節(jié)最后附上真實(shí)環(huán)境里最容易踩的幾個(gè)坑和排查手法。1. 項(xiàng)目概述與需求解析1.1 標(biāo)題背后的三個(gè)關(guān)鍵拆解先把“多協(xié)議網(wǎng)絡(luò)庫設(shè)計(jì)”這七個(gè)字拆開看?！岸鄥f(xié)議”說的是一個(gè)庫要承載多種協(xié)議棧。常見的情況有三類一類是網(wǎng)關(guān)場景外部客戶端用的協(xié)議五花八門服務(wù)端要做協(xié)議轉(zhuǎn)換另一類是SDK場景客戶端庫要支持多種負(fù)載均衡策略、多種網(wǎng)絡(luò)環(huán)境自動(dòng)切換還有一類是中間件場景消息隊(duì)列或RPC框架要同時(shí)支持TCP私有協(xié)議和HTTP訪問。不管哪類本質(zhì)都是希望上層業(yè)務(wù)代碼能復(fù)用連接管理、數(shù)據(jù)收發(fā)、超時(shí)等公共能力而把協(xié)議的差異收斂到編解碼層?！熬W(wǎng)絡(luò)庫”意味著它不是一套業(yè)務(wù)系統(tǒng)而是一個(gè)基礎(chǔ)設(shè)施級別的組件?；A(chǔ)設(shè)施的第一原則是穩(wěn)定第二原則是可控。你不可能在每個(gè)請求路徑上都做高代價(jià)的加鎖或拷貝所以設(shè)計(jì)上會(huì)大量涉及無鎖隊(duì)列、內(nèi)存復(fù)用、IO多路復(fù)用這類手段?！霸O(shè)計(jì)”這詞很關(guān)鍵。它強(qiáng)調(diào)的不是把某個(gè)協(xié)議實(shí)現(xiàn)一遍而是把多種協(xié)議接入方式編排進(jìn)一套統(tǒng)一的模型里。這個(gè)模型是否清晰直接決定后續(xù)加協(xié)議的成本是兩天還是兩周。1.2 核心需求與邊界劃分我在規(guī)劃初期列過一張需求清單其實(shí)核心就是四點(diǎn)第一連接生命周期統(tǒng)一管理。不管是TCP長連接還是WebSocket底層都有建立、傳輸、關(guān)閉、異常這幾個(gè)狀態(tài)必須統(tǒng)一。第二協(xié)議擴(kuò)展成本要低。新增一個(gè)協(xié)議時(shí)不能動(dòng)公共的連接層和事件循環(huán)。第三讀寫模型要高效。要支持大量長連接內(nèi)存開銷不能隨連接數(shù)線性爆炸。第四可觀測性要好。連接斷開、解碼失敗、緩沖區(qū)積壓都要有跡可循。邊界也要?jiǎng)澢宄＞W(wǎng)絡(luò)庫不負(fù)責(zé)業(yè)務(wù)冪等不負(fù)責(zé)數(shù)據(jù)持久化不負(fù)責(zé)服務(wù)發(fā)現(xiàn)和負(fù)載均衡。這些東西如果全塞進(jìn)網(wǎng)絡(luò)庫里最后一定變成一個(gè)誰都不敢動(dòng)的“大泥球”。我的經(jīng)驗(yàn)是網(wǎng)絡(luò)庫里只留連接、協(xié)議、事件三件事其他都通過回調(diào)或插件透傳出去。2. 整體架構(gòu)設(shè)計(jì)與核心抽象2.1 四層架構(gòu)傳輸、事件、協(xié)議、應(yīng)用接口我把這個(gè)庫分成了四個(gè)層次每一層只依賴下一層不允許跨層調(diào)用。傳輸層直接面對socket fd負(fù)責(zé)注冊到事件循環(huán)、執(zhí)行讀寫、關(guān)閉連接完成TCP、UDP等原始傳輸能力。事件層對傳輸層抽象成Channel和Handler兩種實(shí)體。Channel負(fù)責(zé)維護(hù)連接上下文Handler處理讀就緒、寫完成、連接建立、連接關(guān)閉等事件。協(xié)議編排層包含編解碼器Codec、協(xié)議對象Protocol、編解碼鏈CodecChain。每一種協(xié)議在這里獨(dú)立實(shí)現(xiàn)。應(yīng)用接口層對外暴露connect/listen/send/close等API同時(shí)提供業(yè)務(wù)回調(diào)的注冊入口。傳輸層和事件層的分離很多人會(huì)忽略。直接在傳輸層里摻雜事件分發(fā)邏輯初期沒問題等到協(xié)議多起來你會(huì)發(fā)現(xiàn)每個(gè)協(xié)議都在里面if一下代碼會(huì)變得一團(tuán)糟。分層之后每種協(xié)議只需要在協(xié)議編排層啟動(dòng)時(shí)注冊自己的編解碼器連接層完全不感知協(xié)議存在。2.2 協(xié)議抽象層統(tǒng)一數(shù)據(jù)入口與出口協(xié)議抽象層的設(shè)計(jì)是這個(gè)庫的靈魂。我的做法是定義兩種統(tǒng)一結(jié)構(gòu)。一種是網(wǎng)絡(luò)事件NetworkEvent分為連接事件、數(shù)據(jù)事件、關(guān)閉事件三類。不管是TCP收到字節(jié)流還是WebSocket收到一幀消息最終都轉(zhuǎn)換成一個(gè)統(tǒng)一的數(shù)據(jù)事件。另一種是協(xié)議編解碼接口要求每個(gè)協(xié)議實(shí)現(xiàn)decode和encode兩個(gè)方法。偽碼大概是下面這個(gè)樣子public interface Codec { // 將原始字節(jié)流解析為業(yè)務(wù)消息列表返回消費(fèi)了多少字節(jié) ListMessage decode(ByteBuffer input); // 將業(yè)務(wù)消息編碼為字節(jié)流 ByteBuffer encode(Message message); }decode接口的返回值設(shè)計(jì)成“消息列表”而不是單條消息這是一個(gè)很小的細(xì)節(jié)但很實(shí)用。TCP是流協(xié)議一次read可能同時(shí)包含多條業(yè)務(wù)消息只返回一條會(huì)導(dǎo)致剩余數(shù)據(jù)滯留在緩沖區(qū)里被迫再走一遍事件循環(huán)白白增加一次拷貝。UDP和TCP在這一層開始分叉。UDP是無邊界的每個(gè)包天然對應(yīng)一個(gè)數(shù)據(jù)事件所以它的Codec通常不需要處理粘包但需要處理亂序和丟包這部分要放在協(xié)議上層的會(huì)話模塊里處理。TCP則必須在decode里做拆包。2.3 事件循環(huán)與線程模型選型網(wǎng)絡(luò)庫的線程模型直接決定性能上限也是最容易在后期推倒重來的部分。我的選型經(jīng)驗(yàn)是第一版先做單線程事件循環(huán)兼容和調(diào)優(yōu)成本最低后面再升級到多Reactor。單線程事件循環(huán)是指一個(gè)線程跑epoll/kqueue負(fù)責(zé)所有連接的IO事件分發(fā)。這個(gè)模型在連接數(shù)幾千、QPS幾萬以下完全夠用而且所有狀態(tài)變更都在一個(gè)線程內(nèi)完成天然不需要加鎖。業(yè)務(wù)側(cè)通常有計(jì)算密集或阻塞操作不能直接塞在IO線程里所以要配合一個(gè)業(yè)務(wù)線程池。IO線程收到完整消息后封裝成任務(wù)提交到線程池業(yè)務(wù)線程處理完后再把結(jié)果投遞回IO線程發(fā)送。這里的關(guān)鍵是投遞回IO線程的隊(duì)列必須是無鎖或有界隊(duì)列否則會(huì)出現(xiàn)生產(chǎn)速度遠(yuǎn)大于消費(fèi)速度導(dǎo)致內(nèi)存暴漲的問題。多Reactor模型更適合百萬連接級的場景主Reactor只負(fù)責(zé)accept然后按負(fù)載均衡策略把連接分發(fā)給從Reactor線程處理。從Reactor各自跑一個(gè)epoll實(shí)例彼此之間不共享連接也就不存在跨線程操作連接的問題。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 連接狀態(tài)機(jī)的精細(xì)設(shè)計(jì)連接狀態(tài)機(jī)是網(wǎng)絡(luò)庫里最容易寫亂的地方也是問題最多的地方。很多同學(xué)以為狀態(tài)機(jī)就是拿一個(gè)枚舉標(biāo)記一下當(dāng)前的連接階段但實(shí)際上一套完善的TCP連接狀態(tài)應(yīng)該拆成四個(gè)視圖應(yīng)用層狀態(tài)、socket狀態(tài)、讀端狀態(tài)、寫端狀態(tài)。我建議至少維護(hù)以下幾類狀態(tài)CONNECTINGTCP握手進(jìn)行中此時(shí)禁止發(fā)送業(yè)務(wù)數(shù)據(jù)。ESTABLISHED正常讀寫狀態(tài)。LOCAL_CLOSING本地發(fā)起關(guān)閉等待對端響應(yīng)或超時(shí)。REMOTE_CLOSING對端關(guān)閉了寫端本地還在處理殘余數(shù)據(jù)。CLOSED連接已完全釋放。區(qū)分LOCAL_CLOSING和REMOTE_CLOSING是有講究的。TCP是雙通道一端調(diào)用了close之后另一端還能繼續(xù)收到數(shù)據(jù)直到收到FIN為止。如果狀態(tài)機(jī)里沒有半關(guān)閉的概念很容易發(fā)生數(shù)據(jù)發(fā)送到一半被截?cái)嗟膯栴}。實(shí)踐上可以把讀端關(guān)閉和寫端關(guān)閉分開處理讀端關(guān)閉意味著不再接收新數(shù)據(jù)寫端關(guān)閉意味著不再發(fā)送數(shù)據(jù)兩個(gè)都關(guān)閉才算連接真正結(jié)束。常見的坑是連接異常斷開時(shí)只走了一個(gè)錯(cuò)誤回調(diào)沒有把狀態(tài)機(jī)推進(jìn)到CLOSED導(dǎo)致連接對象殘留內(nèi)核緩沖區(qū)中fd泄漏。這個(gè)在壓測時(shí)最明顯連接數(shù)持續(xù)上漲但不回落基本就是狀態(tài)機(jī)沒走全。3.2 讀寫緩沖區(qū)的設(shè)計(jì)與內(nèi)存復(fù)用緩沖區(qū)設(shè)計(jì)直接決定網(wǎng)絡(luò)庫的吞吐和內(nèi)存水位。很多初版實(shí)現(xiàn)會(huì)在每次收到數(shù)據(jù)時(shí)new一個(gè)byte[]發(fā)送時(shí)又new一個(gè)這在低并發(fā)時(shí)沒感覺連接數(shù)一漲GC壓力立馬上來。我的做法是每個(gè)連接里維護(hù)兩個(gè)可動(dòng)態(tài)擴(kuò)容的循環(huán)緩沖區(qū)讀緩沖區(qū)和寫緩沖區(qū)。循環(huán)緩沖區(qū)的核心是維護(hù)讀指針和寫指針typedef struct { uint8_t* data; uint32_t capacity; uint32_t read_pos; uint32_t write_pos; } ring_buffer;寫數(shù)據(jù)前檢查剩余空間不夠就兩倍擴(kuò)容并搬運(yùn)數(shù)據(jù)。這里有一個(gè)優(yōu)化點(diǎn)如果緩沖區(qū)只在單線程中被訪問擴(kuò)容和讀寫完全不需要加鎖但在多Reactor模型的邊界比如業(yè)務(wù)線程把消息投遞給IO線程時(shí)就必須用無鎖隊(duì)列或加鎖保護(hù)否則會(huì)出現(xiàn)數(shù)據(jù)錯(cuò)亂。還有一類優(yōu)化叫分散讀Gather Read。用readv一次把數(shù)據(jù)分散讀到多個(gè)緩沖區(qū)避免先讀進(jìn)臨時(shí)buf再copy到目標(biāo)buf的兩段拷貝。這個(gè)優(yōu)化能省一次內(nèi)存復(fù)制性能提升大概在10%到20%之間在高頻小包場景非常明顯。發(fā)送側(cè)還有個(gè)容易忽略的點(diǎn)不要每次發(fā)送都調(diào)用send要利用內(nèi)核寫緩沖區(qū)和用戶態(tài)寫緩沖區(qū)做合并。先嘗試直接寫socket fd如果返回EAGAIN再把剩余數(shù)據(jù)追加到用戶態(tài)寫緩沖區(qū)等待可寫事件再flush。這樣做可以把多個(gè)小包合并成一次發(fā)送顯著減少系統(tǒng)調(diào)用次數(shù)和TCP分片。3.3 背壓機(jī)制用讀暫停代替盲目丟棄背壓是網(wǎng)絡(luò)庫中最容易被新手忽略的設(shè)計(jì)。當(dāng)業(yè)務(wù)處理速度跟不上上游發(fā)送速度時(shí)連接的內(nèi)核接收緩沖區(qū)和用戶態(tài)讀緩沖區(qū)都會(huì)被填滿此時(shí)如果繼續(xù)讀只會(huì)導(dǎo)致內(nèi)存無限制增長最終OOM。TCP自帶一套流控對端發(fā)的數(shù)據(jù)填滿我方接收緩沖區(qū)后內(nèi)核會(huì)通知對端窗口歸零對端自然停止發(fā)送。網(wǎng)絡(luò)庫要做的就是配合這套流控在用戶態(tài)緩沖區(qū)積壓超過閾值時(shí)暫停讀取。具體實(shí)現(xiàn)里我在讀緩沖區(qū)里設(shè)定高水位線和低水位線。當(dāng)寫入讀緩沖區(qū)的數(shù)據(jù)超過高水位線就從事件循環(huán)中摘除讀事件讓內(nèi)核的接收緩沖區(qū)填滿觸發(fā)TCP背壓。當(dāng)業(yè)務(wù)線程消費(fèi)完緩沖區(qū)的數(shù)據(jù)水位降到低水位線以下再重新注冊讀事件。這里有個(gè)經(jīng)驗(yàn)之談高低水位之間一定要留足緩沖空間否則會(huì)出現(xiàn)頻繁的注冊/摘除抖動(dòng)白白浪費(fèi)兩次epoll_ctl系統(tǒng)調(diào)用。我一般設(shè)置高水位為64KB低水位為16KB合并在一條數(shù)據(jù)事件中判斷實(shí)測下來沒有出現(xiàn)過抖動(dòng)。WebSocket和HTTP這類應(yīng)用層協(xié)議也有自己的背壓考慮比如WebSocket的流量控制可以通過調(diào)整幀長度來協(xié)商但底層的讀取暫停機(jī)制是一樣的。3.4 定時(shí)器與超時(shí)管理的取舍長連接網(wǎng)絡(luò)庫必須要處理三類超時(shí)空閑超時(shí)、連接建立超時(shí)、業(yè)務(wù)超時(shí)。最樸素的實(shí)現(xiàn)是每個(gè)連接掛一個(gè)系統(tǒng)計(jì)時(shí)器到了時(shí)間就回調(diào)關(guān)閉。但如果連接數(shù)有幾十萬直接依賴系統(tǒng)定時(shí)器完全是災(zāi)難。更可靠的方式是使用時(shí)間輪或?qū)蛹墪r(shí)間輪。層級時(shí)間輪把時(shí)間按輪次分級插入和刪除都是O(1)復(fù)雜度特別適合海量連接的心跳管理。我在庫里實(shí)現(xiàn)了兩層時(shí)間輪第一層精度為1秒一圈60格第二層是某公司自己實(shí)現(xiàn)的簡化版本所以你也可以直接用現(xiàn)成的hash wheel timer做改造但核心思想是一樣的——把超時(shí)事件按槽位組織每秒只檢查當(dāng)前槽位上的事件集合而不是遍歷所有連接。上代碼思路class TimingWheel { int current_slot; std::vectorstd::listTimeoutTask* slots; // 每經(jīng)過一個(gè)tick就把當(dāng)前槽位所有任務(wù)取出來檢查 void tick(); };超時(shí)的單位設(shè)置也有講究?？臻e檢測的粒度設(shè)1秒足夠了沒必要追求毫秒級但連接建立超時(shí)一般是幾百毫秒量級因?yàn)閮?nèi)網(wǎng)TCP握手通常很快超過1秒基本可以斷定對端不健康。不要把這兩種超時(shí)混用同一個(gè)定時(shí)器實(shí)例否則會(huì)出現(xiàn)大量的早期喚醒。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 連接生命周期管理實(shí)戰(zhàn)連接對象的生命周期管理建議用兩級引用方式。第一級是事件循環(huán)中的Channel引用它負(fù)責(zé)IO事件分發(fā)第二級是協(xié)議會(huì)話層中的Session引用它承載業(yè)務(wù)狀態(tài)。當(dāng)連接進(jìn)入CLOSED狀態(tài)時(shí)先解除Channel的注冊再通知Session銷毀。銷毀動(dòng)作要特別注意順序。我之前在某個(gè)版本里先銷毀了Session再移除Channel結(jié)果在并發(fā)場景下事件循環(huán)仍然可能拿到Session的懸垂引用直接導(dǎo)致偶發(fā)崩潰。正確順序是先在事件循環(huán)中摘除Channel并停止事件分發(fā)再進(jìn)入業(yè)務(wù)線程池做Session的資源清理最后才是釋放內(nèi)存和fd。連接建立時(shí)還有一個(gè)細(xì)節(jié)。accept返回的fd默認(rèn)沒有設(shè)置非阻塞和TCP_NODELAY如果忘記設(shè)置第一個(gè)業(yè)務(wù)請求就會(huì)出現(xiàn)明顯延遲。其中TCP_NODELAY是專門為了處理小數(shù)據(jù)包場景下的Nagle算法延遲問題這個(gè)開關(guān)在即時(shí)消息類業(yè)務(wù)里必須打開。4.2 解決半包與粘包的正確姿勢半包與粘包是多協(xié)議網(wǎng)絡(luò)庫設(shè)計(jì)中繞不開的話題。很多人遇到這類問題第一個(gè)反應(yīng)是“加大接收緩沖區(qū)”這治標(biāo)不治本。比如業(yè)務(wù)消息長度是10萬個(gè)字節(jié)你的緩沖區(qū)設(shè)得再大也不可能無限大所以必須從協(xié)議解碼上去解決。三種常見的拆包方案定長協(xié)議每個(gè)包長度固定讀取到指定字節(jié)數(shù)就解析。這種最簡單適用控制指令類場景但欠缺靈活性。分隔符協(xié)議以特定字符作為包邊界適合文本協(xié)議比如HTTP的頭部以\r\n\r\n結(jié)束。隱患是消息內(nèi)容里如果包含分隔符必須做轉(zhuǎn)義。長度字段協(xié)議包頭里固定位置存一個(gè)長度字段先讀包頭拿到長度后再讀包體。這是適用范圍最廣的通用方案。實(shí)際生產(chǎn)中用得最多的是第三種而且頭部的長度字段往往和頭部的各種標(biāo)記位在一個(gè)復(fù)合結(jié)構(gòu)里。我當(dāng)時(shí)在協(xié)議編排層實(shí)現(xiàn)了統(tǒng)一的拆包器支持“頭長度已知包體長度未知”的增量解析模式。流程如下先只消費(fèi)固定字節(jié)的包頭解析出包體長度如果讀緩沖區(qū)中剩余字節(jié)小于包體長度就返回等待如果夠了就完整讀取并組裝成一條消息。拆包器的關(guān)鍵實(shí)現(xiàn)點(diǎn)在于解析失敗時(shí)不能盲目地跳過數(shù)據(jù)。我加了解碼失敗計(jì)數(shù)連續(xù)失敗達(dá)到一定閾值就主動(dòng)斷開連接。這個(gè)防守策略曾經(jīng)幫我們擋住了好幾次惡意客戶端的畸形報(bào)文攻擊。4.3 協(xié)議注冊與路由的實(shí)現(xiàn)當(dāng)庫里有多種協(xié)議時(shí)怎么讓一條連接知道自己該用哪個(gè)Codec我的做法是在監(jiān)聽端口上做區(qū)分不同協(xié)議綁定不同的端口或路徑每個(gè)監(jiān)聽器在建立連接時(shí)就把對應(yīng)的Codec掛到連接上下文里后續(xù)的數(shù)據(jù)解析全程使用這個(gè)Codec不需要?jiǎng)討B(tài)探測協(xié)議類型。這種做法成本最低、最容易排查。雖然有一種做法叫協(xié)議嗅探根據(jù)連接的前幾個(gè)字節(jié)猜測協(xié)議類型但它消耗CPU且誤判率不可控生產(chǎn)環(huán)境我基本不建議使用。具體到代碼層我定義了一個(gè)協(xié)議注冊表protocols: dict[str, Codec] { mqtt: MqttCodec(), websocket: WebSocketCodec(), binary: BinaryCodec() } # 連接建立時(shí)根據(jù)監(jiān)聽器配置分配 codec路由到業(yè)務(wù)層時(shí)我采用“消息類型回調(diào)函數(shù)”的訂閱模式。每種協(xié)議的業(yè)務(wù)消息都帶一個(gè)消息類型ID協(xié)議編排層解碼后把它轉(zhuǎn)換成內(nèi)部統(tǒng)一的消息對象業(yè)務(wù)層根據(jù)類型ID分發(fā)到對應(yīng)的處理器。因?yàn)榻y(tǒng)一了消息對象網(wǎng)關(guān)后面接的多個(gè)業(yè)務(wù)服務(wù)就可以用同一條分發(fā)鏈路不必針對每種協(xié)議各寫一套路由邏輯。4.4 壓測埋點(diǎn)與基準(zhǔn)數(shù)據(jù)觀察不要等全部功能上線才開始做性能驗(yàn)證。我在開發(fā)過程中維護(hù)了一套基準(zhǔn)實(shí)驗(yàn)每完成一個(gè)階段就壓測一次重點(diǎn)觀察幾個(gè)指標(biāo)每秒新建連接數(shù)CPS、每秒請求數(shù)QPS、內(nèi)存增長率、以及讀寫緩沖區(qū)的高水位。壓測工具有很多現(xiàn)成的但有一點(diǎn)需要特別留意壓測客戶端必須和服務(wù)端跑在不同的機(jī)器上否則網(wǎng)卡中斷會(huì)相互影響數(shù)據(jù)完全失真。還有一個(gè)容易踩的坑是壓測時(shí)打開了太多TIME_WAIT連接導(dǎo)致客戶端新連接失敗。壓測前把客戶端的端口范圍和復(fù)用參數(shù)調(diào)好是基本功。5. 常見問題與排查技巧實(shí)錄5.1 連接卡“死”卻不報(bào)錯(cuò)都是水位線在作怪出現(xiàn)過幾次詭異問題連接看起來是好的可數(shù)據(jù)就是發(fā)不進(jìn)去。排查到最后全是對端背壓導(dǎo)致我方寫緩沖區(qū)積壓而事件循環(huán)里沒有把可寫事件重新掛上。具體一點(diǎn)說當(dāng)調(diào)用send遇到EAGAIN后數(shù)據(jù)就轉(zhuǎn)存到了用戶態(tài)寫緩沖區(qū)同時(shí)向事件循環(huán)注冊寫事件。如果此時(shí)邏輯上又對同一連接調(diào)用了send且消息太小內(nèi)核對socket可寫的判斷依然成立那么寫事件回調(diào)可能被高頻觸發(fā)但每次只能寫出一小部分?jǐn)?shù)據(jù)。如果處理不當(dāng)會(huì)讓CPU空轉(zhuǎn)看起來就是“連接死了”。解法就是引入寫隊(duì)列的合并機(jī)制限制單次事件回調(diào)中寫操作的上限把剩余數(shù)據(jù)留到下個(gè)事件周期再寫。5.2 從“偶發(fā)崩潰”到“懸垂引用”的排查有個(gè)版本的庫在長時(shí)間運(yùn)行后會(huì)出現(xiàn)偶發(fā)coredump最詭異的是觸發(fā)頻率非常低一天也就兩三次。用調(diào)試工具跟蹤堆棧后發(fā)現(xiàn)是指向已釋放Session的懸垂指針。追蹤原因是主動(dòng)關(guān)閉連接的線程和在事件循環(huán)中執(zhí)行回調(diào)的線程并發(fā)操作了同一個(gè)連接對象。排查關(guān)鍵在于復(fù)現(xiàn)我壓測時(shí)專門構(gòu)造了“頻繁心跳超時(shí)大量并發(fā)連接”的測試場景連續(xù)跑兩小時(shí)必現(xiàn)問題。修復(fù)方式也比較簡單——所有連接狀態(tài)變更的操作統(tǒng)一收斂到IO線程中完成禁止業(yè)務(wù)線程直接調(diào)用close。業(yè)務(wù)層如果想關(guān)閉連接只能投遞一個(gè)關(guān)閉任務(wù)到IO線程由IO線程在下一個(gè)事件循環(huán)中執(zhí)行。5.3 緩沖區(qū)膨脹導(dǎo)致的“假內(nèi)存泄漏”網(wǎng)絡(luò)庫長時(shí)間運(yùn)行后內(nèi)存只漲不降第一反應(yīng)肯定是內(nèi)存泄漏。但真正查了以后發(fā)現(xiàn)內(nèi)存池空閑列表太長碎片化嚴(yán)重導(dǎo)致內(nèi)存始終無法歸還給操作系統(tǒng)。尤其是每次擴(kuò)容都按兩倍增長時(shí)之前分配的大塊緩沖區(qū)會(huì)被“永久”掛在空閑鏈表中。這個(gè)問題有兩個(gè)維度的解法。一是給緩沖區(qū)池設(shè)置空閑上限超過閾值就把多余緩沖區(qū)釋放回系統(tǒng)二是把大緩沖區(qū)分成不同的規(guī)格比如4KB、16KB、64KB各維護(hù)一個(gè)池子按需從對應(yīng)規(guī)格池取用減少碎片化。5.4 線程池中業(yè)務(wù)阻塞拖垮IO線程多協(xié)議網(wǎng)絡(luò)庫中IO線程和業(yè)務(wù)線程是分離的但有些同事圖省事直接在IO回調(diào)里做耗時(shí)計(jì)算比如發(fā)起同步數(shù)據(jù)庫查詢。一次兩次看不出來并發(fā)一上來IO線程全部卡在業(yè)務(wù)邏輯上事件分發(fā)瞬間停擺整個(gè)服務(wù)的TCP連接開始批量超時(shí)。這就是架構(gòu)容忍度的紅線。我在項(xiàng)目規(guī)范里明確寫了IO線程中只允許做不阻塞的操作所有同步阻塞調(diào)用必須丟到業(yè)務(wù)線程池。如果協(xié)議本身要求立即響應(yīng)且耗時(shí)不可控就啟用獨(dú)立的連接處理線程把它從公共事件循環(huán)中剝離出去。5.5 排查速查表現(xiàn)象常見原因排查步驟解決方案連接數(shù)上漲后回落慢連接狀態(tài)機(jī)未走完打印連接關(guān)閉日志觀察CLOSED狀態(tài)補(bǔ)齊關(guān)閉事件回調(diào)小包吞吐上不去Nagle算法未禁用檢查TCP_NODELAY連接accept后立即設(shè)置內(nèi)存只漲不降緩沖池碎片化觀察池內(nèi)空閑塊數(shù)量設(shè)置空閑池上限數(shù)據(jù)偶發(fā)截?cái)喟腙P(guān)閉狀態(tài)未處理抓包看FIN位置區(qū)分讀關(guān)閉和寫關(guān)閉對端頻繁斷連心跳超時(shí)太短查看超時(shí)日志調(diào)大空閑超時(shí)或時(shí)間輪精度寫在最后的一個(gè)體會(huì)這個(gè)項(xiàng)目做下來我個(gè)人最大的體會(huì)是設(shè)計(jì)多協(xié)議網(wǎng)絡(luò)庫時(shí)最難的部分不是對某個(gè)協(xié)議的細(xì)節(jié)了解得多深而是能不能抽象出一套足夠穩(wěn)定的連接模型。連接狀態(tài)機(jī)畫得越精細(xì)背壓機(jī)制做得越穩(wěn)妥緩沖區(qū)和定時(shí)器這些底層設(shè)施越扎實(shí)上層協(xié)議接入就越輕松。如果你現(xiàn)在剛準(zhǔn)備動(dòng)手做類似的東西我建議不要一上來就追求多協(xié)議。先寫一個(gè)TCP私有協(xié)議跑通全鏈路再把WebSocket接進(jìn)來有了兩個(gè)對比后自然就會(huì)發(fā)現(xiàn)公共的抽象點(diǎn)在哪里。到第三個(gè)協(xié)議時(shí)你基本不需要?jiǎng)舆B接層的代碼了。等到架構(gòu)穩(wěn)定再回頭補(bǔ)性能分散讀、無鎖隊(duì)列、內(nèi)存池每一步優(yōu)化都有明確的目標(biāo)和老舊的瓶頸做參照。這個(gè)輪子造完以后業(yè)務(wù)側(cè)接入新協(xié)議的時(shí)間從按周算壓縮到了按天算這是我們當(dāng)時(shí)最大的收益。當(dāng)然它不能替代消息中間件和RPC框架但在需要自己定制協(xié)議和連接策略的場景里一套結(jié)構(gòu)清晰的多協(xié)議網(wǎng)絡(luò)庫還是很能打的。