1. 把一次網(wǎng)絡(luò)讀寫拆到內(nèi)核里看線上有個(gè)服務(wù)QPS 壓到三千左右就上不去了機(jī)器 CPU 看著不高但top里sy系統(tǒng)態(tài)占比一直壓在 40% 以上load也不高連接數(shù)上不去也不掉。一開始懷疑是數(shù)據(jù)庫換了幾輪慢查詢優(yōu)化沒效果后來又懷疑帶寬不對抓包一看每個(gè)請求的往返都很正常。最后把線程棧 dump 下來發(fā)現(xiàn)幾百個(gè)工作線程全卡在同一個(gè)recv調(diào)用上一半在等數(shù)據(jù)、一半在等鎖。問題不在業(yè)務(wù)代碼在于整個(gè)服務(wù)的網(wǎng)絡(luò) IO 模型選錯(cuò)了——線程池 阻塞 IO 硬扛長連接連接一多線程全變擺設(shè)。這就是我想聊的話題。網(wǎng)絡(luò) IO 模型說白了就一件事當(dāng)程序要讀網(wǎng)絡(luò)上的數(shù)據(jù)而數(shù)據(jù)還沒到的時(shí)候你的程序該干什么。是原地卡住等還是先回去干別的、過會兒再來問一遍還是干脆交給一個(gè)“哨兵”統(tǒng)一盯著誰的數(shù)據(jù)到了再通知誰。這五種做法就是常說的阻塞 IO、非阻塞 IO、IO 多路復(fù)用、信號驅(qū)動(dòng) IO、異步 IO。它們不是教科書里的名詞游戲每一種背后都對應(yīng)著一筆真實(shí)的成本賬線程數(shù)、內(nèi)存占用、上下文切換次數(shù)、以及你愿不愿意接受一定的編程復(fù)雜度。這篇文章寫給三類人。第一類是寫業(yè)務(wù)代碼的平時(shí)用框架用得很順但遇到連接數(shù)暴漲、超時(shí)莫名其妙、CPU 空轉(zhuǎn)這些問題時(shí)不知道該往哪個(gè)方向查第二類是準(zhǔn)備自己寫網(wǎng)絡(luò)服務(wù)的選型的時(shí)候需要知道每種模型的天花板在哪第三類是要應(yīng)對面試和架構(gòu)評審的光背“五種模型”的定義沒用得能說清楚為什么主流選擇是 epoll 那一套、為什么異步 IO 喊了這么多年落地卻不算多。下面的內(nèi)容我會從內(nèi)核里的一次讀操作開始拆一路講到代碼怎么寫、線上怎么排查。所有參數(shù)和步驟我都會給出為什么這么定而不是直接甩結(jié)論。1.1 從網(wǎng)卡到用戶緩沖區(qū)一次讀事件的完整路徑很多人對網(wǎng)絡(luò) IO 的理解停在“read 一個(gè) socket 拿到數(shù)據(jù)”中間發(fā)生了什么是一片模糊。這片模糊恰恰是后面所有模型差異的來源所以必須先講清楚。假設(shè)客戶端發(fā)來一個(gè)數(shù)據(jù)包。網(wǎng)卡收到電信號通過 DMA 把數(shù)據(jù)寫進(jìn)內(nèi)核里預(yù)先分配好的環(huán)形緩沖區(qū)ring buffer硬件隨即發(fā)一個(gè)中斷。內(nèi)核的中斷處理程序不會當(dāng)場把數(shù)據(jù)一路解析上去那樣太慢它只做最輕量的事把數(shù)據(jù)包掛到軟中斷待處理隊(duì)列然后盡快返回。真正的協(xié)議棧處理在軟中斷里完成逐層剝掉以太網(wǎng)頭、IP 頭、TCP 頭根據(jù)四元組找到對應(yīng)的 socket把載荷數(shù)據(jù)追加到該 socket 的接收緩沖區(qū)里。如果這個(gè) socket 上掛著一個(gè)正在睡眠等待的進(jìn)程內(nèi)核喚醒它把它從等待隊(duì)列里挪回可運(yùn)行隊(duì)列。到這一步為止數(shù)據(jù)已經(jīng)在內(nèi)核緩沖區(qū)里躺著了但你的程序還沒看見它。程序要真正拿到這段字節(jié)還需要一次數(shù)據(jù)拷貝從內(nèi)核空間的 socket 接收緩沖區(qū)復(fù)制到用戶空間你聲明的那塊內(nèi)存里。這次拷貝是 CPU 參與的繞不開除非用零拷貝那一套但那是另一個(gè)話題普通 socket 讀寫還是要拷。所以一次完整的網(wǎng)絡(luò)讀可以切成兩個(gè)階段階段一等待數(shù)據(jù)就緒數(shù)據(jù)從網(wǎng)卡到內(nèi)核緩沖區(qū)期間你的程序可能什么都做不了。階段二數(shù)據(jù)拷貝從內(nèi)核緩沖區(qū)到用戶緩沖區(qū)期間 CPU 在干活但你的程序依然處于系統(tǒng)調(diào)用之中。記住這兩個(gè)階段后面五種模型的區(qū)別全都在于“這兩個(gè)階段里進(jìn)程到底在不在等、等在哪”。我在實(shí)際調(diào)試中經(jīng)常用一個(gè)很土的辦法驗(yàn)證這個(gè)路徑在服務(wù)端recv之前加日志然后用ss -m看對應(yīng)連接的接收隊(duì)列。如果 Recv-Q 有值而你的程序還沒讀到說明數(shù)據(jù)已經(jīng)在內(nèi)核里了程序卡在階段二的入口如果 Recv-Q 是 0 而程序還在阻塞那就是階段一沒等到東西。這個(gè)判斷方法很粗糙但定位方向極其有效比盲目加日志快得多。順帶說一個(gè)容易忽略的點(diǎn)TCP 的接收窗口和內(nèi)核接收緩沖區(qū)是綁定的。如果你的程序讀得慢內(nèi)核緩沖區(qū)堆滿接收窗口就會縮小到零發(fā)送方被流控卡住。這時(shí)候表現(xiàn)出的“網(wǎng)絡(luò)慢”其實(shí)是應(yīng)用層讀得太慢不是帶寬問題。我在一個(gè)數(shù)據(jù)同步的場景里就遇到過對方一直抱怨傳輸慢最后發(fā)現(xiàn)是消費(fèi)端每次只讀 1KB內(nèi)核緩沖區(qū)堆了 200KB 讀不出去。1.2 兩個(gè)階段的劃分決定了所有模型的差異把兩個(gè)階段攤開五種模型的差別就一目了然了我先用一段話把它們串起來后面再逐個(gè)拆。阻塞 IO兩個(gè)階段都在等。發(fā)起調(diào)用后進(jìn)程被掛起數(shù)據(jù)到了、拷貝完了才返回。等待期間這個(gè)線程什么都干不了。非阻塞 IO第一個(gè)階段不等。調(diào)用立刻返回沒數(shù)據(jù)就告訴你沒數(shù)據(jù)errno 為 EAGAIN程序自己決定過多久再來問一次。第二個(gè)階段還是同步的數(shù)據(jù)拷貝時(shí)進(jìn)程仍然在系統(tǒng)調(diào)用里。IO 多路復(fù)用第一個(gè)階段交給一個(gè)專門的系統(tǒng)調(diào)用去等。你一次性把一批 fd 注冊進(jìn)去這個(gè)調(diào)用會阻塞在那里直到其中任意一個(gè)可讀可寫。也就是說一個(gè)線程能盯住成千上萬個(gè)連接。但注意它只是幫你“等到”拷貝還是你自己調(diào)recv來做所以本質(zhì)上仍然是同步 IO。信號驅(qū)動(dòng) IO第一個(gè)階段連等都不用等。注冊一個(gè)信號處理函數(shù)數(shù)據(jù)就緒時(shí)內(nèi)核發(fā) SIGIO 給你你在信號處理里再調(diào)recv。理論上很優(yōu)雅實(shí)際用得極少后面會說原因。異步 IO兩個(gè)階段都不需要你管。你發(fā)起一個(gè)讀請求附帶一塊緩沖區(qū)和回調(diào)或者一個(gè)完成事件然后立刻返回。內(nèi)核把數(shù)據(jù)等到、并且拷貝進(jìn)你給的緩沖區(qū)之后才通知你“完事了”。這是真正的異步和前面四種有本質(zhì)區(qū)別。這里有個(gè)特別常見的誤解就是把 IO 多路復(fù)用當(dāng)成異步 IO。很多文章寫著“NIO 就是非阻塞異步”這個(gè)說法很不嚴(yán)謹(jǐn)。Java 的 NIO 名字叫 Non-blocking I/O但它用的是多路復(fù)用底層是 epollSelector.select()返回可讀之后你還是得自己調(diào)channel.read()把數(shù)據(jù)從內(nèi)核拷到 ByteBuffer 里這一步是同步的。真正對標(biāo)異步 IO 的是 JDK 7 引入的 NIO.2AIO或者 Linux 上的 io_uring。判斷一個(gè) IO 是同步還是異步標(biāo)準(zhǔn)只有一條數(shù)據(jù)從內(nèi)核緩沖區(qū)到用戶緩沖區(qū)這一步是誰在做進(jìn)程有沒有被阻塞。只要這一步是進(jìn)程自己調(diào)用的那就是同步不管前面等得多花哨。這條標(biāo)準(zhǔn)我在評審方案時(shí)反復(fù)用能擋掉一大堆名詞包裝。理解了這層再看一個(gè)具體的現(xiàn)象為什么有些服務(wù)線程數(shù)不多但能扛上萬連接因?yàn)樗央A段一交給了 epoll一個(gè)線程盯幾千個(gè) fd只有真正有數(shù)據(jù)的連接才會被分配線程去處理階段二。這就是事件驅(qū)動(dòng)的基本盤。反過來如果服務(wù)是一連接一線程的阻塞模型一萬連接就是一萬個(gè)線程光線程棧默認(rèn) 8MB實(shí)際虛擬內(nèi)存物理頁按需分配和內(nèi)核調(diào)度開銷就能把機(jī)器拖垮。2. 五種網(wǎng)絡(luò) IO 模型的逐個(gè)拆解與適用邊界這一段是全文的主體我盡量把每種模型“為什么是這樣設(shè)計(jì)的”“在什么情況下會翻車”講透。不講空話每個(gè)結(jié)論都配一個(gè)能驗(yàn)證它的現(xiàn)象。2.1 阻塞 IO最簡單也最容易被誤用的模型阻塞 IO 的調(diào)用鏈非常直白accept沒有新連接就卡住recv沒有數(shù)據(jù)就卡住send發(fā)送緩沖區(qū)滿了也卡住。進(jìn)程被放進(jìn) socket 的等待隊(duì)列狀態(tài)變成可中斷睡眠CPU 完全不占用。數(shù)據(jù)到了內(nèi)核喚醒它它繼續(xù)往下走。它的優(yōu)點(diǎn)就一個(gè)字簡單。代碼是線性的讀完了就處理處理完了就寫回去心智負(fù)擔(dān)為零。所以它在兩類場景里活得很好。一類是連接數(shù)很少的內(nèi)部服務(wù)比如一個(gè)管理后臺幾十個(gè)并發(fā)用阻塞 IO 加線程池完全夠用沒必要上事件驅(qū)動(dòng)。另一類是配合“一連接一線程”的模型做短連接服務(wù)請求處理很快連接生命周期很短線程復(fù)用池子能兜住。但它有兩個(gè)硬傷第一個(gè)是線程和連接綁定。假設(shè)每個(gè)連接平均每秒只有 10 個(gè)請求單次處理耗時(shí) 5ms那么這個(gè)連接 99.5% 的時(shí)間是空閑的可它依然占著一個(gè)線程。線程本身的開銷分幾塊內(nèi)核里的 task_struct、用戶態(tài)的棧、調(diào)度器維護(hù)的運(yùn)行隊(duì)列節(jié)點(diǎn)還有上下文切換的成本。線程數(shù)上千之后調(diào)度器的紅黑樹操作和緩存失效會明顯拖慢整體sy占比會明顯上升。第二個(gè)硬傷是阻塞調(diào)用會傳染。你在一個(gè)請求里串行調(diào)了三個(gè)下游服務(wù)每個(gè)都可能卡住最壞情況下這個(gè)線程被占用的時(shí)間等于三個(gè)超時(shí)之和。如果下游抖動(dòng)線程池很快被耗干新請求進(jìn)來排隊(duì)超時(shí)擴(kuò)散最終整個(gè)服務(wù)雪崩。我做壓測時(shí)見過一個(gè)典型現(xiàn)象并發(fā)從 500 加到 800TP99 從 80ms 跳到 3 秒但 CPU 使用率反而下降——這就是線程池打滿、大量線程在等下游的典型特征。要緩解就得給每個(gè)阻塞調(diào)用設(shè)超時(shí)并且用SO_RCVTIMEO或應(yīng)用層超時(shí)把等待時(shí)間卡住。但超時(shí)只是止血不解決根本問題你依然為每個(gè)連接付出了線程成本。一個(gè)經(jīng)驗(yàn)判斷如果你的服務(wù)連接數(shù)長期在幾百以內(nèi)、單次處理耗時(shí)可控、沒有大量長連接比如推送、IM、訂閱阻塞 IO 加線程池是最省心的選擇。別為了“先進(jìn)”去上事件驅(qū)動(dòng)事件驅(qū)動(dòng)的代碼復(fù)雜度和調(diào)試難度是另一個(gè)量級。還有一個(gè)坑要說清楚阻塞 IO 在accept上也有講究。監(jiān)聽 socket 默認(rèn)是阻塞的如果accept返回后你處理連接花了很久期間新連接會堆在 backlog 隊(duì)列里。backlog 大小由listen(fd, backlog)指定實(shí)際生效值還受net.core.somaxconn限制。這兩個(gè)值不一致的時(shí)候以小的為準(zhǔn)。很多服務(wù)連接建立慢、握手超時(shí)就是 backlog 給太小了。生產(chǎn)環(huán)境我會把somaxconn調(diào)到 4096 以上listen傳 1024 起步具體看連接建立速率。2.2 非阻塞 IO輪詢的代價(jià)與適用場景非阻塞 IO 就是把 fd 設(shè)成O_NONBLOCK然后調(diào)用立刻返回。沒數(shù)據(jù)時(shí)返回 -1 并置 errno 為 EAGAIN 或 EWOULDBLOCK在 Linux 上這兩個(gè)值相同。程序可以立刻去干別的事過會兒再來問。聽起來很美好但如果你真的寫一個(gè)while(true) { n recv(fd, buf, len, 0); if (n 0) break; }的循環(huán)你會發(fā)現(xiàn) CPU 直接 100%而且大部分時(shí)間在做無意義的系統(tǒng)調(diào)用。這就是忙輪詢是最糟糕的用法。系統(tǒng)調(diào)用本身有成本要從用戶態(tài)切到內(nèi)核態(tài)保存寄存器檢查權(quán)限處理完再切回來。一次可能幾百納秒但一秒做幾十萬次就是實(shí)打?qū)嵉拈_銷且這些開銷全部記賬在sy上。所以非阻塞 IO 單獨(dú)用幾乎沒有意義它必須和別的東西配合。最常見的配合方式有三種第一種是和多路復(fù)用配合這也是絕大多數(shù)場景的做法。先用 epoll 等到某個(gè) fd 就緒再對這個(gè) fd 用非阻塞方式讀寫。為什么就緒了還要非阻塞因?yàn)?epoll 的通知是“曾經(jīng)可讀”等你真正去讀的時(shí)候可能已經(jīng)被別的線程讀走了或者數(shù)據(jù)只到了一部分。非阻塞在這里是兜底保證你永遠(yuǎn)不會因?yàn)橐淮巫x寫把線程卡死。第二種是帶退避的輪詢。每次 EAGAIN 之后 sleep 一小段時(shí)間再來。這種方式在極低延遲要求的場景下偶爾用比如某些交易系統(tǒng)的行情拉取但絕大多數(shù)業(yè)務(wù)沒必要。退避時(shí)間的選擇很講究太短沒意義太長丟延遲。第三種是非阻塞加自旋加協(xié)程調(diào)度。協(xié)程庫在遇到 EAGAIN 時(shí)會把當(dāng)前協(xié)程掛起把 CPU 讓給別的協(xié)程等 fd 就緒了再喚醒。對上層來說代碼是同步寫法實(shí)際執(zhí)行是事件驅(qū)動(dòng)的。這也是現(xiàn)在很多語言 runtime 的做法。這里必須點(diǎn)出一個(gè)常見誤區(qū)把 socket 設(shè)成非阻塞并不等于性能變好。非阻塞只是改變了“等待”的方式并沒有減少數(shù)據(jù)拷貝也沒有減少系統(tǒng)調(diào)用次數(shù)。如果你的程序邏輯還是“讀一次處理一次”非阻塞帶來的只是更復(fù)雜的錯(cuò)誤處理代碼。真正帶來吞吐提升的是多路復(fù)用帶來的“一個(gè)線程管多連接”。我在實(shí)際項(xiàng)目里給 fd 設(shè)非阻塞的時(shí)機(jī)很固定accept返回的新連接立刻設(shè)connect發(fā)起前設(shè)非阻塞 connect 可以避免三次握手期間卡住然后用 epoll 監(jiān)聽可寫事件判斷連接是否建立成功監(jiān)聽 fd 本身視模型而定。這個(gè)順序不能亂尤其是connect如果先連再設(shè)非阻塞那在連接超時(shí)的情況下你還是會被卡住。2.3 IO 多路復(fù)用select、poll、epoll 的三代演進(jìn)這一節(jié)是重點(diǎn)因?yàn)樗悄壳皫缀跛懈咝阅芫W(wǎng)絡(luò)服務(wù)的底座。select是最早的方案。它用一個(gè)位圖fd_set表示要監(jiān)聽哪些 fd調(diào)用時(shí)把這個(gè)位圖從用戶態(tài)拷到內(nèi)核態(tài)內(nèi)核遍歷一遍看哪些 fd 有事件把有事件的 fd 在位圖里標(biāo)記出來再拷回用戶態(tài)。程序拿到返回值后還得自己再遍歷一遍位圖找出哪些位被置位了。它有三個(gè)致命問題。第一fd 數(shù)量上限是FD_SETSIZE通常是 1024改這個(gè)值要重新編譯內(nèi)核不現(xiàn)實(shí)。第二每次調(diào)用都要把整個(gè)位圖拷進(jìn)拷出fd 越多拷貝越大這是 O(n) 的內(nèi)存拷貝。第三內(nèi)核要線性掃描所有 fd用戶態(tài)也要線性掃描兩次 O(n)。所以 select 在 fd 上千之后性能急劇下滑而且每次調(diào)用完都得重置 fd_set很容易寫錯(cuò)。poll換了個(gè)數(shù)據(jù)結(jié)構(gòu)用pollfd數(shù)組每個(gè)元素包含 fd、關(guān)心的事件、返回的事件。它解決了 1024 上限的問題上限變成內(nèi)存和ulimit -n決定的也解決了每次要重置的問題events 和 revents 分離。但本質(zhì)沒變還是每次全量拷貝還是內(nèi)核線性掃描還是用戶態(tài)線性掃描。fd 到一萬這個(gè)量級poll 的拷貝和掃描開銷就很可觀了。epoll是 Linux 2.6 引入的思路完全不一樣把“注冊”和“等待”拆成兩個(gè)操作。epoll_create在內(nèi)核里創(chuàng)建一個(gè) eventpoll 對象里面維護(hù)兩塊核心結(jié)構(gòu)一棵紅黑樹用來存所有注冊進(jìn)來的 fd 及其關(guān)注的事件一個(gè)就緒鏈表用來存已經(jīng)有事件發(fā)生的 fd。紅黑樹保證增刪改是 O(log n)就緒鏈表保證取事件是 O(1)。epoll_ctl負(fù)責(zé)往紅黑樹里加、刪、改。關(guān)鍵是注冊的時(shí)候內(nèi)核會給這個(gè) fd 掛一個(gè)回調(diào)當(dāng)該 fd 對應(yīng)的數(shù)據(jù)到達(dá)、觸發(fā)軟中斷處理時(shí)內(nèi)核直接通過這個(gè)回調(diào)把 fd 塞進(jìn)就緒鏈表。也就是說事件是被主動(dòng)推送過來的不需要掃描。epoll_wait只做一件事看就緒鏈表空不空?？站退强站桶焰湵砝锏墓?jié)點(diǎn)拷到一個(gè)用戶傳入的數(shù)組里返回同時(shí)把這個(gè)節(jié)點(diǎn)從鏈表摘掉水平觸發(fā)模式下會重新掛回去后面細(xì)說。返回值是就緒的 fd 個(gè)數(shù)用戶只需要處理這 n 個(gè)不需要遍歷全部。這三個(gè)改進(jìn)疊加起來效果是注冊一次長期有效事件驅(qū)動(dòng)無需掃描只返回就緒的處理量與總連接數(shù)無關(guān)。這就是所謂的 O(1) 事件通知嚴(yán)格說是 O(就緒數(shù))不是 O(總連接數(shù))。但 epoll 不是沒有成本有幾個(gè)點(diǎn)必須知道第一epoll_ctl的調(diào)用是有開銷的比 select 的一次性注冊攤薄下來要貴。所以如果你的場景是“一批 fd 用一次就扔”比如處理一批短連接select 或 poll 反而可能更劃算。epoll 的優(yōu)勢在長連接、高頻復(fù)用。第二epoll 的紅黑樹節(jié)點(diǎn)和就緒鏈表節(jié)點(diǎn)都是內(nèi)核內(nèi)存連接數(shù)巨大時(shí)這部分內(nèi)存不可忽視。粗略估算每個(gè)被監(jiān)聽的 fd 在內(nèi)核里額外占幾百字節(jié)不同內(nèi)核版本有差異量級在數(shù)百字節(jié)十萬連接就是幾十 MB 的額外開銷。做容量規(guī)劃時(shí)要把這塊算進(jìn)去。第三epoll_wait返回的數(shù)組大小要合理。傳 1 意味著每次只能取一個(gè)就緒事件雖然不會丟但會多調(diào)用很多次傳太大又浪費(fèi)棧或堆空間。我一般按min(預(yù)期并發(fā)就緒數(shù), 1024)來定實(shí)測下來 512 到 1024 是個(gè)舒適區(qū)。第四跨進(jìn)程或者多線程同時(shí)epoll_wait同一個(gè) epoll 實(shí)例會涉及喚醒競爭也就是常說的驚群。Linux 4.5 引入的EPOLLEXCLUSIVE標(biāo)志可以緩解同一時(shí)刻只喚醒一個(gè)等待者另一個(gè)思路是用SO_REUSEPORT讓每個(gè)線程各自持有獨(dú)立的監(jiān)聽 fd 和獨(dú)立的 epoll 實(shí)例。這兩套方案我在不同項(xiàng)目里都用過后者在多核下擴(kuò)展性更好但連接分配的均衡性依賴內(nèi)核哈希不能保證完全均勻。2.4 信號驅(qū)動(dòng)與異步IO一條容易被混淆的邊界信號驅(qū)動(dòng) IO的流程是給 socket 設(shè)置屬主并注冊 SIGIO 處理函數(shù)開啟信號驅(qū)動(dòng)然后進(jìn)程就可以去干別的。數(shù)據(jù)到達(dá)時(shí)內(nèi)核發(fā) SIGIO進(jìn)程在信號處理函數(shù)里調(diào)recv讀數(shù)據(jù)。它的問題很實(shí)際。首先信號處理函數(shù)里能做的事情非常受限很多庫函數(shù)不是異步信號安全的一不小心就死鎖。其次信號是進(jìn)程級的多個(gè) fd 共用一個(gè)信號處理函數(shù)里很難判斷到底是哪個(gè) fd 就緒還得額外維護(hù)映射。第三信號可能丟失或合并高頻事件下不可靠。所以這套東西除了少數(shù)嵌入式場景和歷史遺留代碼基本沒人用了。你在網(wǎng)上看到它的介紹知道原理就夠了不用花時(shí)間實(shí)踐。異步 IO才是真正意義上的“不等”。你提交一個(gè)讀請求附帶緩沖區(qū)和完成通知方式立刻返回。內(nèi)核負(fù)責(zé)等數(shù)據(jù)、負(fù)責(zé)拷貝全干完了再告訴你。整個(gè)過程中你的進(jìn)程一次都沒有被阻塞在 IO 上。Linux 上的實(shí)現(xiàn)經(jīng)歷了兩個(gè)階段。早期是 POSIX AIOglibc 的用戶態(tài)模擬和內(nèi)核 AIOio_submit/io_getevents前者本質(zhì)是用線程池模擬后者限制很多只支持 O_DIRECT、對普通文件的支持不好、網(wǎng)絡(luò) IO 支持有限一直沒能普及。近些年 io_uring 出來了用一對共享內(nèi)存的環(huán)形隊(duì)列提交隊(duì)列和完成隊(duì)列來做用戶態(tài)和內(nèi)核態(tài)的通信既支持文件 IO 也支持網(wǎng)絡(luò) IO還能批量提交通過IORING_SETUP_SQPOLL讓內(nèi)核線程輪詢提交隊(duì)列進(jìn)一步減少系統(tǒng)調(diào)用。它的性能數(shù)據(jù)很漂亮但生態(tài)還在成熟過程中各種語言的綁定質(zhì)量參差不齊線上大規(guī)模用的案例還不算多。至于 Java 的 AIONIO.2在 Linux 上底層用的是 epoll 模擬JDK 內(nèi)部有專門的實(shí)現(xiàn)并不是真正的內(nèi)核異步 IO所以它的“異步”更多是 API 層面的封裝。這也是為什么很多 Java 服務(wù)依然選 Netty 而不是 AIO 的原因之一。選型上的建議除非你有非常明確的理由比如已經(jīng)在用 io_uring 做存儲棧、或者對系統(tǒng)調(diào)用次數(shù)極度敏感網(wǎng)絡(luò)服務(wù)的默認(rèn)答案就是 epoll 這一套多路復(fù)用加事件循環(huán)。異步 IO 的收益在當(dāng)前階段還不足以抵消它的復(fù)雜度和生態(tài)風(fēng)險(xiǎn)。下面這張表是我自己在做方案對比時(shí)用的把關(guān)鍵維度擺在一起看比讀十篇介紹文章都直觀。模型階段一等數(shù)據(jù)階段二拷貝單線程可管理連接數(shù)編程復(fù)雜度典型適用場景阻塞 IO進(jìn)程阻塞進(jìn)程阻塞1與線程綁定低連接少、內(nèi)部服務(wù)、短連接非阻塞 IO輪詢不阻塞進(jìn)程阻塞取決于輪詢策略中一般需配合其他模型使用IO 多路復(fù)用由內(nèi)核代為等待進(jìn)程阻塞數(shù)千至數(shù)十萬中高長連接網(wǎng)關(guān)、推送、代理信號驅(qū)動(dòng) IO信號通知不阻塞進(jìn)程阻塞理論上多實(shí)際受限高極少使用異步 IO內(nèi)核完成內(nèi)核完成高高高吞吐存儲、特定場景3. 把 epoll 真正跑起來從調(diào)用到事件循環(huán)理論講完落到代碼。這一段我會把 epoll 的關(guān)鍵調(diào)用拆開說明每個(gè)參數(shù)為什么這么填然后給出一個(gè)能直接編譯運(yùn)行的最小事件循環(huán)再對照 Java NIO 的寫法方便不同技術(shù)棧的讀者對照理解。3.1 epoll 三個(gè)調(diào)用背后的數(shù)據(jù)結(jié)構(gòu)與參數(shù)含義epoll_create1(EPOLL_CLOEXEC)創(chuàng)建一個(gè) epoll 實(shí)例返回一個(gè) fd。參數(shù)用EPOLL_CLOEXEC而不是老的epoll_create(size)原因是前者會在exec新程序時(shí)自動(dòng)關(guān)閉這個(gè) fd避免子進(jìn)程繼承一堆用不上的句柄。老接口的size參數(shù)在內(nèi)核 2.6.8 之后已經(jīng)沒意義了只是兼容保留不要以為它真的能限制什么。epoll_ctl(epfd, op, fd, event)是增刪改。op有 ADD、DEL、MOD 三種。event里兩個(gè)字段最要緊events是關(guān)注的事件掩碼data是一個(gè)聯(lián)合體可以存 fd 也可以存指針。我強(qiáng)烈建議存指針而不是 fd因?yàn)樵诟卟l(fā)場景下你需要通過這個(gè)字段快速定位到連接對象包含緩沖區(qū)、狀態(tài)機(jī)、超時(shí)時(shí)間等存 fd 的話還要再查一次哈希表白白多一次間接尋址。存指針的做法是把連接對象的地址塞進(jìn)data.ptr事件回來時(shí)直接強(qiáng)轉(zhuǎn)。events里常填的EPOLLIN可讀、EPOLLOUT可寫、EPOLLERR錯(cuò)誤、EPOLLHUP掛斷、EPOLLRDHUP對端關(guān)閉寫端這個(gè)很有用能提前感知半關(guān)閉。注意EPOLLERR和EPOLLHUP是永遠(yuǎn)會被上報(bào)的不需要你顯式注冊但你應(yīng)該在事件處理里優(yōu)先檢查它們。epoll_wait(epfd, events, maxevents, timeout)是等待。timeout單位毫秒-1 表示永久阻塞0 表示立即返回純輪詢正數(shù)表示最多等這么久。這里有個(gè)實(shí)操細(xì)節(jié)很多事件循環(huán)會把 timeout 設(shè)成一個(gè)較小的值比如 100ms 或者按最近的定時(shí)器到期時(shí)間算目的是定期醒來處理定時(shí)任務(wù)連接超時(shí)、心跳檢測。如果設(shè) -1那定時(shí)任務(wù)就永遠(yuǎn)沒機(jī)會執(zhí)行。我一般的做法是算出“距離下一個(gè)定時(shí)器還有多少毫秒”作為 timeout 傳進(jìn)去這樣既不空轉(zhuǎn)也不誤事。調(diào)用返回值 n 表示就緒的事件數(shù)接下來遍歷events[0..n-1]逐個(gè)處理。處理時(shí)有個(gè)原則單個(gè)事件的處理時(shí)間要盡可能短。如果某個(gè)連接的業(yè)務(wù)處理很重不要在這個(gè)循環(huán)里做完應(yīng)該丟給業(yè)務(wù)線程池。否則一個(gè)慢請求會拖住整個(gè)事件循環(huán)所有連接都受影響。這是事件驅(qū)動(dòng)模型最容易被違反的原則也是很多自研框架的性能瓶頸所在。3.2 水平觸發(fā)與邊緣觸發(fā)丟數(shù)據(jù)的坑都在這兒這是 epoll 里最容易出問題的地方我必須單獨(dú)講。水平觸發(fā)LT默認(rèn)的語義是只要 fd 的接收緩沖區(qū)里還有數(shù)據(jù)沒讀完每次epoll_wait都會告訴你這個(gè) fd 可讀。也就是說你讀了一半就走了下次還會被通知不會丟。這個(gè)模式寫起來安全因?yàn)槟隳呐轮蛔x了一個(gè)字節(jié)剩下的下次還能拿到。代價(jià)是如果一直不讀完就會一直被通知形成忙循環(huán)所以還是要讀完。邊緣觸發(fā)ET的語義是只在狀態(tài)發(fā)生變化時(shí)通知一次。從“無數(shù)據(jù)”變成“有數(shù)據(jù)”時(shí)通知之后無論緩沖區(qū)里還剩多少都不再通知直到下一次新的數(shù)據(jù)到達(dá)。這就要求你收到通知后必須循環(huán)讀取直到返回 EAGAIN把緩沖區(qū)徹底讀空。同時(shí) fd 必須是非阻塞的否則最后一次讀會因?yàn)闆]數(shù)據(jù)而阻塞住把整個(gè)事件循環(huán)卡死。我在一個(gè)項(xiàng)目里就踩過這個(gè)坑代碼改成了 ET 模式但讀取邏輯還是只讀一次。壓測時(shí)表現(xiàn)為極低概率的數(shù)據(jù)丟失大概萬分之一的請求少字段。排查了兩天才定位到原因是某個(gè)請求的數(shù)據(jù)包被拆成了兩段第一段到達(dá)觸發(fā)了一次通知程序讀完第一段就去處理了第二段到達(dá)時(shí)因?yàn)榫彌_區(qū)非空狀態(tài)沒變化不再觸發(fā)通知于是第二段永遠(yuǎn)留在內(nèi)核緩沖區(qū)里直到下一個(gè)包到達(dá)才被順帶讀出來——所以表現(xiàn)為“偶發(fā)丟數(shù)據(jù)”而不是“必丟”。這種 bug 極難復(fù)現(xiàn)因?yàn)橐蕾嚲W(wǎng)絡(luò)分包。所以 ET 模式的正確寫法固定是三段式for (;;) { n read(fd, buf, len); if (n 0) { 處理 } else if (n 0) { 對端關(guān)閉清理 } else { if (errno EAGAIN || errno EWOULDBLOCK) break; else 出錯(cuò)處理 } }。這個(gè)循環(huán)不能省。選用建議沒有明確性能訴求就用 LT。ET 的優(yōu)勢在于減少epoll_wait的返回次數(shù)在高并發(fā)下能省一些系統(tǒng)調(diào)用但差距沒有想象中大通常 10% 以內(nèi)而它帶來的正確性風(fēng)險(xiǎn)是實(shí)打?qū)嵉摹Ｖ挥性谶B接數(shù)極高、且你對自己的讀取邏輯非常有信心時(shí)才上 ET。另外要注意監(jiān)聽 fdlisten返回的那個(gè)在 ET 模式下也要循環(huán)accept直到 EAGAIN否則并發(fā)連接建立時(shí)會漏掉一部分連接。3.3 一份可復(fù)用的最小事件循環(huán)先看 C 版本這段代碼我用了很多次去掉業(yè)務(wù)邏輯就是一個(gè)干凈的骨架。#include sys/epoll.h #include sys/socket.h #include fcntl.h #include unistd.h #include errno.h #include stdio.h #define MAX_EVENTS 1024 static int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main(void) { int listenfd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); /* bind listen 略backlog 建議 1024 起 */ set_nonblocking(listenfd); int epfd epoll_create1(EPOLL_CLOEXEC); struct epoll_event ev, events[MAX_EVENTS]; ev.events EPOLLIN; /* 監(jiān)聽 fd 用水平觸發(fā)穩(wěn) */ ev.data.fd listenfd; epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, ev); for (;;) { /* timeout 按最近定時(shí)器到期時(shí)間算這里固定 100ms 演示 */ int n epoll_wait(epfd, events, MAX_EVENTS, 100); if (n 0) { if (errno EINTR) continue; /* 被信號打斷重來 */ perror(epoll_wait); break; } for (int i 0; i n; i) { int fd events[i].data.fd; if (events[i].events (EPOLLERR | EPOLLHUP)) { close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); continue; } if (fd listenfd) { for (;;) { /* 循環(huán) accept 直到 EAGAIN */ int conn accept(listenfd, NULL, NULL); if (conn 0) { if (errno EAGAIN || errno EWOULDBLOCK) break; if (errno EINTR) continue; break; } set_nonblocking(conn); ev.events EPOLLIN | EPOLLRDHUP; ev.data.fd conn; epoll_ctl(epfd, EPOLL_CTL_ADD, conn, ev); } } else { /* 業(yè)務(wù)讀取這里若用 ET 必須循環(huán)讀到 EAGAIN */ char buf[4096]; ssize_t r read(fd, buf, sizeof(buf)); if (r 0) { /* 處理數(shù)據(jù) */ } else if (r 0) { close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); } else { if (errno ! EAGAIN errno ! EWOULDBLOCK) { close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); } } } } } return 0; }這段代碼里有幾個(gè)地方值得單獨(dú)說。EINTR的處理不能省因?yàn)檫M(jìn)程可能被信號打斷epoll_wait會返回 -1如果不判斷就直接退出服務(wù)會因?yàn)橐粋€(gè)無關(guān)信號掛掉。EPOLLRDHUP加進(jìn)去是為了盡早感知對端關(guān)閉否則你可能要等一次寫失敗才知道對面走了。epoll_ctl DEL在 close 之前還是之后其實(shí)都可以因?yàn)?close 會自動(dòng)把 fd 從 epoll 里移除但顯式 DEL 更清晰也避免 fd 被復(fù)用后出現(xiàn)意外。再看 Java NIO 的等價(jià)寫法思路完全一樣只是把系統(tǒng)調(diào)用包裝成了對象。Selector selector Selector.open(); ServerSocketChannel server ServerSocketChannel.open(); server.bind(new InetSocketAddress(8080), 1024); server.configureBlocking(false); server.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 1000ms 是為了兜底定時(shí)任務(wù) int n selector.select(1000); if (n 0) continue; IteratorSelectionKey it selector.selectedKeys().iterator(); while (it.hasNext()) { SelectionKey key it.next(); it.remove(); // 必須移除否則下次重復(fù)處理 if (!key.isValid()) continue; if (key.isAcceptable()) { SocketChannel ch server.accept(); ch.configureBlocking(false); ch.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { SocketChannel ch (SocketChannel) key.channel(); ByteBuffer buf ByteBuffer.allocate(4096); int r ch.read(buf); if (r -1) { key.cancel(); ch.close(); } else if (r 0) { buf.flip(); /* 處理 */ } } } }it.remove()這一行是新手最容易漏的。selectedKeys()返回的集合是復(fù)用的你不移除下一輪還會處理同一個(gè) key業(yè)務(wù)邏輯會重復(fù)執(zhí)行。這個(gè) bug 的表現(xiàn)是“請求被處理了兩次”在冪等接口上不明顯在扣款類操作上就是事故。Java 側(cè)還有兩個(gè)細(xì)節(jié)configureBlocking(false)必須在register之前調(diào)用否則會拋異常allocate每個(gè)連接都新建一個(gè) ByteBuffer 會造成大量小對象生產(chǎn)環(huán)境要用池化或者直接緩沖區(qū)。這些在 Netty 里都被封裝好了但知道底層在干什么出問題時(shí)才能定位。4. 從模型到架構(gòu)Reactor 與線程模型的取舍搞清楚了單個(gè)連接怎么處理下一個(gè)問題是怎么把成千上萬個(gè)連接和有限的 CPU 核數(shù)組織起來。這就是 Reactor 模式要回答的事。4.1 三種 Reactor 結(jié)構(gòu)與它們的成本賬單 Reactor 單線程是最樸素的形態(tài)一個(gè)線程跑事件循環(huán)accept、讀、業(yè)務(wù)處理、寫全在里面。它的好處是無鎖、無競爭、邏輯簡單壞處是任何一步慢都會拖住全部。適合業(yè)務(wù)極輕的場景比如某些協(xié)議轉(zhuǎn)換、簡單的回顯服務(wù)。用它跑有數(shù)據(jù)庫訪問的業(yè)務(wù)基本上是自找麻煩。單 Reactor 多線程把業(yè)務(wù)處理挪出去事件循環(huán)只負(fù)責(zé) IO 讀寫和編解碼讀完的完整報(bào)文丟給業(yè)務(wù)線程池。這樣 IO 和計(jì)算解耦一個(gè)慢查詢不會阻塞其他連接的數(shù)據(jù)接收。代價(jià)是線程間傳遞數(shù)據(jù)要做隊(duì)列隊(duì)列滿了要有背壓策略而且寫操作要從業(yè)務(wù)線程回到 IO 線程涉及跨線程提交任務(wù)。這里的坑是寫并發(fā)多個(gè)業(yè)務(wù)線程同時(shí)想往同一個(gè)連接寫數(shù)據(jù)直接寫會導(dǎo)致字節(jié)流交錯(cuò)必須加鎖或者串行化到 IO 線程。主從 Reactor更進(jìn)一步把 accept 也分離出來主 Reactor 只負(fù)責(zé)監(jiān)聽和建立連接建立后把新連接分給某個(gè)從 Reactor從 Reactor 各自跑自己的事件循環(huán)處理讀寫。這樣 accept 的壓力不會影響已有連接而且從 Reactor 的數(shù)量可以按 CPU 核數(shù)擴(kuò)展通常設(shè)成核數(shù)或核數(shù)的 1 到 2 倍。這是目前主流框架的默認(rèn)模型。分連接的方式通常有兩種輪詢和按連接 id 取模。輪詢實(shí)現(xiàn)簡單但需要原子計(jì)數(shù)高并發(fā)下有競爭取模無競爭但依賴連接 id 分布均勻。我在實(shí)際項(xiàng)目里更傾向輪詢因?yàn)檫B接 id 不一定連續(xù)取模可能傾斜。這里有個(gè)成本賬要算清楚從 Reactor 線程數(shù)不是越多越好。每個(gè)線程有自己的 epoll 實(shí)例、自己的事件循環(huán)、自己的隊(duì)列。線程多了鎖競爭雖然少了但上下文切換和緩存局部性會變差。我實(shí)測下來從 Reactor 線程數(shù)設(shè)成 CPU 核數(shù)時(shí)吞吐最好超過 1.5 倍核數(shù)基本沒有收益反而 P99 會抖動(dòng)。這個(gè)結(jié)論在不同業(yè)務(wù)下會有差異但量級上差不多。4.2 連接數(shù)、線程數(shù)與內(nèi)存容量估算的實(shí)際算法做架構(gòu)評審時(shí)經(jīng)常被問“這套模型能扛多少連接”很多人答不上來。其實(shí)可以算我心里有個(gè)固定的算法。先算文件描述符。每個(gè)連接占一個(gè) fd服務(wù)端自己還要占一些監(jiān)聽、日志、管道、epoll 實(shí)例、定時(shí)器留 200 個(gè)余量比較穩(wěn)。所以ulimit -n至少要等于目標(biāo)連接數(shù)加上 200。這里要注意ulimit -n是每進(jìn)程的限制還有fs.file-max是系統(tǒng)級限制兩個(gè)都要調(diào)。改ulimit可以在啟動(dòng)腳本里ulimit -n 1048576也可以通過 systemd 的LimitNOFILE配。改完記得驗(yàn)證用cat /proc/pid/limits看實(shí)際生效值。再算內(nèi)核內(nèi)存。每個(gè) TCP 連接在內(nèi)核里有 socket 結(jié)構(gòu)、發(fā)送緩沖區(qū)、接收緩沖區(qū)。緩沖區(qū)大小受net.ipv4.tcp_rmem和tcp_wmem控制是三元組最小、默認(rèn)、最大。默認(rèn)值通常接收 128KB 左右、發(fā)送 16KB 左右但這是上限實(shí)際按需增長。保守估算每連接 200KB 內(nèi)核內(nèi)存十萬連接就是 20GB。這個(gè)數(shù)字經(jīng)常被忽略結(jié)果連接一多就 OOM。生產(chǎn)上我會把默認(rèn)值調(diào)小一點(diǎn)比如接收 64KB讓緩沖區(qū)按需增長避免空閑連接占著大塊內(nèi)存。再算應(yīng)用層內(nèi)存。每個(gè)連接對象、讀緩沖區(qū)、寫緩沖區(qū)、狀態(tài)機(jī)、定時(shí)器節(jié)點(diǎn)加起來通常幾 KB 到幾十 KB。這里的關(guān)鍵是讀寫緩沖區(qū)別開太大。有的框架默認(rèn)給每個(gè)連接分配 64KB 讀緩沖十萬連接就是 6.4GB。實(shí)際做法是用可變緩沖區(qū)初始 1KB 到 4KB不夠再擴(kuò)并且設(shè)上限。最后算線程棧。Java 默認(rèn)每線程 1MB可用-Xss調(diào)小到 256KBC 的 pthread 默認(rèn) 8MB虛擬內(nèi)存實(shí)際按需分配。線程數(shù)按 Reactor 核數(shù)加業(yè)務(wù)線程池來估通常幾十到幾百這塊開銷不大。真正占內(nèi)存的是連接對象不是線程。把這些加起來就是一臺機(jī)器的內(nèi)存需求。我給個(gè)參考十萬長連接4KB 應(yīng)用層緩沖加 64KB 內(nèi)核緩沖加對象開銷大約 8 到 12GB需要配 16GB 內(nèi)存的機(jī)器并且把 fd 限制調(diào)到 12 萬以上。這個(gè)估算在幾個(gè)項(xiàng)目里驗(yàn)證過誤差在 20% 以內(nèi)。4.3 背壓與應(yīng)用層協(xié)議的配合模型選對了還有一個(gè)隱形的坑上游讀得飛快下游寫得慢。事件循環(huán)不停地把數(shù)據(jù)讀進(jìn)來放進(jìn)隊(duì)列業(yè)務(wù)線程處理不過來隊(duì)列無限增長最后內(nèi)存爆掉。這就是沒有背壓。背壓的手段分幾層。最直接的是停止讀當(dāng)某個(gè)連接的待處理隊(duì)列超過閾值就從 epoll 里把這個(gè) fd 的 EPOLLIN 事件摘掉用epoll_ctl MOD改成只監(jiān)聽 EPOLLOUT或者干脆 DEL 掉這樣內(nèi)核緩沖區(qū)堆滿后TCP 接收窗口縮小發(fā)送方自然減速。這一招最干凈因?yàn)樗褖毫鲗?dǎo)回了源頭符合 TCP 的設(shè)計(jì)初衷。第二層是限制并發(fā)處理數(shù)。業(yè)務(wù)線程池用有界隊(duì)列隊(duì)列滿了就拒絕或者阻塞提交。這里的取舍是阻塞提交會讓 IO 線程被卡住不可取拒絕則要有一套降級邏輯比如返回特定錯(cuò)誤碼讓客戶端重試。我一般用有界隊(duì)列加拒絕隊(duì)列容量按“能承受的最大積壓時(shí)間”來定比如目標(biāo) P99 是 100ms處理速度是每秒 1 萬那隊(duì)列 1000 左右比較合適。第三層是協(xié)議層限流。比如在報(bào)文頭里帶一個(gè)序號或者窗口大小讓客戶端自己控制發(fā)送速率。這在自研協(xié)議里很常見用標(biāo)準(zhǔn)協(xié)議的話就得靠 TCP 自身的流控。我見過最典型的背壓缺失案例一個(gè)推送服務(wù)客戶端網(wǎng)絡(luò)慢服務(wù)端不停往里寫寫緩沖區(qū)從幾 KB 漲到幾 MB幾千個(gè)慢客戶端直接把內(nèi)存吃光。修復(fù)方案是給每個(gè)連接設(shè)寫緩沖上限超過就斷開或者丟棄舊消息。斷開這個(gè)動(dòng)作看著粗暴但對推送場景是合理的因?yàn)榉e壓的消息本來就已經(jīng)過期了。另外應(yīng)用層協(xié)議的選擇也會反向影響模型。比如 HTTP/1.1 的 keep-alive 讓連接變長就必須用多路復(fù)用模型HTTP/2 的多路復(fù)用是在一條連接上跑多個(gè)流需要應(yīng)用層自己做流控WebSocket 是長連接雙向通信對事件循環(huán)的寫并發(fā)要求更高。這些在選擇協(xié)議的時(shí)候就得想清楚別等上線了才發(fā)現(xiàn)模型不匹配。5. 線上排查實(shí)錄那些模型理論解釋不了的現(xiàn)象理論和代碼講完最后落到排查。這一節(jié)全是我在實(shí)際環(huán)境里遇到過的現(xiàn)象和對應(yīng)的定位路徑很多問題光看模型定義是看不出來的。5.1 高頻問題速查表先給一張表按現(xiàn)象查起?，F(xiàn)象優(yōu)先懷疑快速驗(yàn)證方法常見處理CPU 的 sy 占比高但吞吐上不去事件循環(huán)空轉(zhuǎn)、系統(tǒng)調(diào)用過多strace -c -p pid看調(diào)用次數(shù)檢查 timeout 是否設(shè)成 0 或過小檢查是否有忙輪詢連接數(shù)上不去accept報(bào)錯(cuò)fd 限制、backlog 太小cat /proc/pid/limits、ss -lnt看 Send-Q調(diào)ulimit -n、調(diào)大somaxconn和 listen backlog大量 CLOSE_WAIT 堆積應(yīng)用層沒正確關(guān)閉連接ss -tan state close-wait | wc -l檢查讀到 EOF 后是否 close檢查異常路徑是否漏關(guān)偶發(fā)丟數(shù)據(jù)低頻難復(fù)現(xiàn)ET 模式?jīng)]循環(huán)讀完抓包對比應(yīng)用層收到的字節(jié)數(shù)改為循環(huán)讀到 EAGAIN或退回 LT某幾個(gè)連接延遲極高單個(gè)事件處理太慢拖住循環(huán)在事件循環(huán)里埋點(diǎn)統(tǒng)計(jì)單次處理耗時(shí)把重業(yè)務(wù)移出 IO 線程內(nèi)存持續(xù)增長不釋放寫緩沖無上限、連接對象泄漏看堆內(nèi)連接對象數(shù)量和緩沖大小分布設(shè)緩沖上限加空閑連接回收多線程 accept 時(shí)部分連接不處理epoll 驚群觀察是否所有線程都被喚醒用 EPOLLEXCLUSIVE 或 SO_REUSEPORT這張表里的每一條我都在真實(shí)環(huán)境驗(yàn)證過。尤其是 ET 那條抓包對比是最直接的在服務(wù)端用 tcpdump 抓一段數(shù)一下某個(gè)請求的 payload 總字節(jié)數(shù)再和應(yīng)用層日志里收到的字節(jié)數(shù)對比。如果抓包比日志多基本可以確定是讀循環(huán)沒讀干凈。5.2 幾個(gè)必須提前規(guī)避的細(xì)節(jié)第一個(gè)epoll_wait返回后別在遍歷中直接 DEL 當(dāng)前 fd 之外的 fd。這個(gè)坑很隱蔽。你手里拿著一個(gè) events 數(shù)組遍歷到第 3 個(gè)元素時(shí)業(yè)務(wù)邏輯順手關(guān)掉了第 5 個(gè)元素對應(yīng)的連接并 DEL 了。等遍歷到第 5 個(gè)時(shí)那個(gè) fd 可能已經(jīng)被新連接復(fù)用了你去處理它操作的是完全不相干的連接。正確做法是先把所有事件收集起來處理完再統(tǒng)一做增刪或者用引用計(jì)數(shù)延遲釋放。我在一個(gè)網(wǎng)關(guān)項(xiàng)目里因?yàn)檫@個(gè) bug 排查了整整一周現(xiàn)象是“極低概率的串包”A 用戶收到了 B 用戶的響應(yīng)。第二個(gè)信號要處理好。事件循環(huán)里被 SIGPIPE 打斷會導(dǎo)致進(jìn)程直接退出默認(rèn)行為。如果客戶端在你寫數(shù)據(jù)時(shí)突然斷開你調(diào)用 write 就會收到 SIGPIPE。要么全局忽略它signal(SIGPIPE, SIG_IGN)要么用send的MSG_NOSIGNAL標(biāo)志。這個(gè)必須加不加就是一顆定時(shí)炸彈平時(shí)不出問題用戶批量斷線重啟時(shí)直接崩。第三個(gè)定時(shí)器精度別依賴epoll_wait的 timeout。那個(gè) timeout 只是“最多等這么久”實(shí)際可能提前返回有事件也可能稍微延后調(diào)度延遲。如果你靠它來做精確的超時(shí)控制誤差會累積。正確做法是自己維護(hù)一個(gè)時(shí)間輪或者最小堆每次算好最近到期時(shí)間作為 timeout同時(shí)每次醒來都檢查一遍當(dāng)前時(shí)間把到期的連接處理掉。第四個(gè)TIME_WAIT 是正常的別急著調(diào)參數(shù)。服務(wù)端主動(dòng)關(guān)閉連接會進(jìn)入 TIME_WAIT占著四元組 60 秒2 倍 MSL。高并發(fā)短連接場景下 TIME_WAIT 數(shù)量會很高很多人第一反應(yīng)是開tcp_tw_reuse或者調(diào)小fin_timeout。但在 NAT 環(huán)境下亂開 reuse 有風(fēng)險(xiǎn)而且 TIME_WAIT 的存在是為了保證最后一個(gè) ACK 能重傳強(qiáng)行消滅會引入數(shù)據(jù)錯(cuò)亂。我的做法是優(yōu)先用長連接和連接池把短連接降下來實(shí)在降不下來再看有沒有足夠的端口范圍最后才考慮內(nèi)核參數(shù)。第五個(gè)不要在事件循環(huán)里做 DNS 解析、文件讀寫、日志刷盤這些阻塞操作。任何一個(gè)都可能耗時(shí)幾十毫秒而這幾十毫秒里所有連接都停擺。DNS 要單獨(dú)起解析線程或用異步解析庫日志用異步 appender文件操作丟線程池。這些看起來是常識但我在不止一個(gè)服務(wù)里見過事件循環(huán)里直接logger.info同步刷盤的。第六個(gè)連接關(guān)閉的順序。正確的關(guān)閉是先shutdown(SHUT_WR)發(fā) FIN 告訴對端我不發(fā)了然后繼續(xù)讀直到讀到 EOF對端也關(guān)了再 close。直接 close 可能會導(dǎo)致發(fā)送緩沖區(qū)里沒發(fā)完的數(shù)據(jù)被丟棄除非設(shè)了 SO_LINGER。在推送類服務(wù)里這個(gè)細(xì)節(jié)很關(guān)鍵直接 close 會導(dǎo)致最后一條消息丟失。寫到這里我個(gè)人的體會其實(shí)很簡單網(wǎng)絡(luò) IO 模型的選擇本質(zhì)上是在“線程成本”和“編程復(fù)雜度”之間做交換。阻塞 IO 把復(fù)雜度留給了運(yùn)行時(shí)線程多、切換多事件驅(qū)動(dòng)把復(fù)雜度留給了開發(fā)者狀態(tài)機(jī)、回調(diào)、緩沖管理。沒有哪一種絕對更好只有適不適合你當(dāng)下的連接規(guī)模、團(tuán)隊(duì)能力和業(yè)務(wù)特征。很多團(tuán)隊(duì)上事件驅(qū)動(dòng)上早了代碼寫成一團(tuán)亂麻問題排查成本遠(yuǎn)超省下來的那點(diǎn)資源。反過來連接數(shù)已經(jīng)過萬了還在用一連接一線程那就是在跟物理規(guī)律較勁。真要給一個(gè)判斷標(biāo)準(zhǔn)我會看兩條連接數(shù)長期穩(wěn)定在 500 以下用阻塞 IO 加線程池超過這個(gè)量級或者有大量空閑長連接就老老實(shí)實(shí)上 epoll 那一套。中間地帶可以先用“阻塞 IO 合理超時(shí) 連接池”過渡等壓測數(shù)據(jù)真的支撐不住了再重構(gòu)別一上來就追求終極方案。