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