絡(luò)庫(kù) netpoll：事件驅(qū)動(dòng)模型與 Reactor 工程實(shí)踐)
如果你用Go寫過(guò)面向高并發(fā)的網(wǎng)絡(luò)服務(wù)一定經(jīng)歷過(guò)這樣的階段一開始標(biāo)準(zhǔn)庫(kù)的net包用得很爽Accept 一個(gè)連接就go一個(gè) goroutine代碼簡(jiǎn)單到不行。等連接數(shù)從幾百漲到幾萬(wàn)goroutine 數(shù)量、內(nèi)存占用、上下文切換一起爆炸CPU profiling 一看調(diào)度器的負(fù)擔(dān)比業(yè)務(wù)代碼還重。這時(shí)候再去搜索 Go 網(wǎng)絡(luò)性能優(yōu)化的方案大概率會(huì)看到一個(gè)名字netpoll。netpoll 是字節(jié)跳動(dòng)開源的高性能網(wǎng)絡(luò)庫(kù)最初是為 Kitex 這類微服務(wù) RPC 框架服務(wù)的。它底層走的是事件驅(qū)動(dòng)模型核心思路和 Redis、Netty 是一路的用少量線程/協(xié)程管理海量連接連接來(lái)了不分配 goroutine而是注冊(cè)事件真正有數(shù)據(jù)可讀可寫時(shí)才觸發(fā)處理。這篇博客我會(huì)站在從業(yè)者的角度把 netpoll 的模型拆開講清楚包括它解決什么問(wèn)題、事件循環(huán)如何工作、連接狀態(tài)怎么流轉(zhuǎn)以及在實(shí)際項(xiàng)目中應(yīng)該怎么用、踩過(guò)哪些坑。無(wú)論你是剛開始看 Go 網(wǎng)絡(luò)編程還是想拿它優(yōu)化自己的 RPC 服務(wù)這篇文章都值得讀完。1. 為什么需要 netpoll 這樣的網(wǎng)絡(luò)模型1.1 標(biāo)準(zhǔn)庫(kù)網(wǎng)絡(luò)模型的天花板在哪里Go 標(biāo)準(zhǔn)庫(kù)的net包在底層其實(shí)已經(jīng)封裝了 epoll/kqueue通過(guò)runtime netpoller實(shí)現(xiàn)了非阻塞 I/O所以標(biāo)準(zhǔn)庫(kù)寫并發(fā)網(wǎng)絡(luò)服務(wù)并不笨。真正的問(wèn)題出在編程模型上標(biāo)準(zhǔn)庫(kù)給到用戶的 API 是“每個(gè)連接一個(gè) goroutine”你用Accept()拿回一個(gè)net.Conn之后想讀想寫直接conn.Read()、conn.Write()就行庫(kù)會(huì)自動(dòng)幫你把 fd 注冊(cè)到全局的網(wǎng)絡(luò)輪詢器中。這個(gè)模型寫起來(lái)很爽但代價(jià)是一個(gè)連接對(duì)應(yīng)一個(gè)常駐 goroutine。連接數(shù)是幾千的時(shí)候還沒(méi)啥感覺(jué)到了十萬(wàn)、百萬(wàn)連接的時(shí)候光 goroutine 的棧內(nèi)存就可能占掉幾百 MB再加上 goroutine 的創(chuàng)建銷毀、調(diào)度器要頻繁切換運(yùn)行隊(duì)列CPU 白白燒掉的太多了。我做過(guò)一個(gè)壓測(cè)同樣一臺(tái) 8C16G 的機(jī)器用標(biāo)準(zhǔn)庫(kù)的net/http寫長(zhǎng)連接服務(wù)連接數(shù)到了 5 萬(wàn)左右goroutine 數(shù)直接沖到 5 萬(wàn)pprof 里看runtime.futex、runtime.schedule的開銷已經(jīng)排到了前幾名。業(yè)務(wù)邏輯其實(shí)很簡(jiǎn)單但調(diào)度和內(nèi)存占用反客為主了。這就是標(biāo)準(zhǔn)庫(kù)模型的第一個(gè)天花板goroutine-per-connection 在連接數(shù)極高時(shí)goroutine 本身成了資源瓶頸。第二個(gè)天花板是標(biāo)準(zhǔn)庫(kù)把底層細(xì)節(jié)封得太死了。你拿到的是一根net.Conn管道它不會(huì)告訴你這個(gè) fd 是不是真的可寫了也不會(huì)給你機(jī)會(huì)批量處理同一次epoll_wait返回的多組事件。標(biāo)準(zhǔn)庫(kù)內(nèi)部的poll.FD是給runtime netpoller用的暴露出來(lái)的接口非常有限你想做更精細(xì)的調(diào)度、想用readv批量接收多個(gè) buffer根本沒(méi)有入口。第三個(gè)天花板是標(biāo)準(zhǔn)庫(kù)的緩沖策略。net.Conn底層的讀緩沖是有限度的TCP 包來(lái)一個(gè)你Read拿走一個(gè)每次 Read 都可能是用戶態(tài)到內(nèi)核態(tài)的一次邊界。對(duì)延遲特別敏感、小包特別多的 RPC 場(chǎng)景來(lái)說(shuō)這種粒度有點(diǎn)粗。1.2 netpoll 的定位從連接模型改為事件模型netpoll 的思路很簡(jiǎn)單把“一個(gè)連接一個(gè) goroutine”改成“一個(gè)事件循環(huán)管一堆連接”。它復(fù)用 epoll/kqueue 的能力讓事件循環(huán)去epoll_wait等具體某個(gè) fd 可讀、可寫時(shí)才回調(diào)處理邏輯。這樣連接數(shù)再多處理這些連接的 goroutine 數(shù)量也是固定的通常等于 CPU 核數(shù)。這種模型最大的優(yōu)勢(shì)在于高連接數(shù)下不會(huì)再有大量 goroutine 被Read阻塞在那里。每個(gè)連接在相安無(wú)事時(shí)只是一個(gè)注冊(cè)在 epoll 里的 fd加一個(gè) connection 對(duì)象若干緩沖區(qū)。CPU 只在真正有數(shù)據(jù)流動(dòng)時(shí)才被喚醒空閑連接幾乎不消耗 CPU 和內(nèi)存。拿我線上一個(gè)實(shí)際例子來(lái)說(shuō)一個(gè)對(duì)外提供長(zhǎng)連接推送的服務(wù)改造前用標(biāo)準(zhǔn)庫(kù)連接峰值 3 萬(wàn)內(nèi)存穩(wěn)定在 1.2GB 左右換成 netpoll 模型之后同樣 3 萬(wàn)連接內(nèi)存降到 400MB 出頭CPU 占用大約低了 30%。原因就是不再為每個(gè)連接保留一個(gè)阻塞著的 goroutine那些 goroutine 的棧、上下文信息就全省下來(lái)了。netpoll 并不是要替代標(biāo)準(zhǔn)庫(kù)在“低并發(fā)、高開發(fā)效率”場(chǎng)景下的地位。它是為解決“海量連接 低延遲 RPC 可控資源”這個(gè)問(wèn)題而生的所以在微服務(wù)框架里應(yīng)用最廣。如果你也在做 RPC、網(wǎng)關(guān)、長(zhǎng)連接推送理解 netpoll 的模型是很有價(jià)值的。2. 核心設(shè)計(jì)事件驅(qū)動(dòng)與 Reactor 模型的工程化落地2.1 事件驅(qū)動(dòng)模型的基本思路事件驅(qū)動(dòng)模型本質(zhì)上是一個(gè)無(wú)限循環(huán)等事件 - 分發(fā)事件 - 處理事件 - 再等事件。對(duì)網(wǎng)絡(luò)層來(lái)說(shuō)這個(gè)“事件”通常就是某個(gè) fd 可讀、可寫、出錯(cuò)。epoll 的作用就是把“操心哪個(gè) fd 有動(dòng)靜”這個(gè)活兒交給內(nèi)核用戶程序只需要epoll_wait阻塞等結(jié)果。netpoll 在這個(gè)基礎(chǔ)上做了一層很細(xì)的封裝。注意Go 里貼到應(yīng)用層的“goroutine”概念和操作系統(tǒng)線程不完全等價(jià)所以 netpoll 的事件循環(huán)并不是說(shuō)每個(gè)循環(huán)綁死一個(gè) OS 線程它還是依托 goroutine 調(diào)度。但它在應(yīng)用層做了一個(gè)“由事件循環(huán)統(tǒng)一 poll fd”的抽象把網(wǎng)絡(luò)事件和用戶業(yè)務(wù)回調(diào)解耦開。我理解 netpoll 的核心抽象分三層EventLoop對(duì)外暴露的事件循環(huán)負(fù)責(zé)啟動(dòng)、停止、注冊(cè)連接Poller對(duì) epoll/kqueue 的封裝負(fù)責(zé)create,ctl,wait這類系統(tǒng)操作Connection一個(gè)連接對(duì)象的抽象包含 fd、讀寫緩沖區(qū)、狀態(tài)、回調(diào)。這種分層我在讀源碼時(shí)感覺(jué)很舒服因?yàn)槊恳粚佣伎梢詥为?dú)替換。例如 Poller 層Linux 上走 epollmacOS/BSD 上走 kqueue業(yè)務(wù)代碼感知不到這就是抽象的價(jià)值。2.2 主從 Reactor 在 netpoll 中的體現(xiàn)傳統(tǒng) Reactor 模型分為 main reactor 和 sub reactor。main reactor 專門負(fù)責(zé) accept 新連接然后把新連接 fd 分發(fā)到某一個(gè) sub reactor 上sub reactor 則負(fù)責(zé)這個(gè)連接后續(xù)的可讀可寫事件。在 netpoll 里這個(gè)思想體現(xiàn)在兩個(gè)層面。第一它一般會(huì)起多個(gè) event loop默認(rèn)runtime.NumCPU()個(gè)新連接會(huì)通過(guò)一定的策略輪詢或者取最小負(fù)載分配給其中一個(gè) loop。第二每個(gè) loop 內(nèi)部是一個(gè)獨(dú)立的epoll_wait循環(huán)它只負(fù)責(zé)屬于這一路 loop 的連接事件。這樣多核 CPU 可以并行處理不同連接的事件不會(huì)因?yàn)橐话汛箧i導(dǎo)致全局阻塞。我當(dāng)時(shí)看到 netpoll 的EventLoop.Serve方法時(shí)第一反應(yīng)是它很像 Netty 的bossGroup和workerGroup的合體版。netpoll 里通常一個(gè) EventLoop 就同時(shí)承擔(dān)了 accept 和讀寫的責(zé)任但它用多個(gè) EventLoop 實(shí)例運(yùn)行來(lái)實(shí)現(xiàn)并行度。如果你對(duì) Netty 比較熟可以把 netpoll 理解成“多 worker 共享 accept 職責(zé)”的變形不夠純粹但是勝在簡(jiǎn)單高效。2.3 為什么在 Go 里還需要自研網(wǎng)絡(luò)庫(kù)可能有讀者會(huì)問(wèn)Go 標(biāo)準(zhǔn)庫(kù)不是已經(jīng)把 epoll 封裝好了嗎為什么還要自研因?yàn)闃?biāo)準(zhǔn)庫(kù)封裝的是一個(gè)通用 I/O 模型它面向的是“阻塞式 API runtime 調(diào)度”。這意味著每個(gè)conn.Read()調(diào)用都會(huì)把這個(gè) goroutine park 住直到數(shù)據(jù)可達(dá)。這是個(gè)傻瓜式的好用 API但代價(jià)是控制權(quán)不在你手里。你沒(méi)有辦法讓 event loop 在一次epoll_wait返回之后只挑出一批“真正該讀”的 fd 來(lái)讀跳過(guò)那些暫時(shí)沒(méi)數(shù)據(jù)的。在 netpoll 這類模型里網(wǎng)絡(luò)處理是顯式狀態(tài)機(jī)。你注冊(cè)了讀事件之后框架在做epoll_wait時(shí)會(huì)把可讀 fd 統(tǒng)統(tǒng)帶回來(lái)你在回調(diào)里明確知道這個(gè) fd 有數(shù)據(jù)于是非阻塞Read。整個(gè)過(guò)程不會(huì)出現(xiàn)“某個(gè) goroutine 掛在 Read 上沉睡”的情況而是“事件來(lái)了我再安排處理”。這個(gè)差異用一句話概括就是標(biāo)準(zhǔn)庫(kù)是一個(gè)連接一個(gè)協(xié)程地“人等數(shù)據(jù)”netpoll 是事件循環(huán)一把梭地“數(shù)據(jù)找人”。另外netpoll 自己還可以掌控內(nèi)存分配、事件批量處理、寫緩沖合并等細(xì)節(jié)。它甚至可以把多個(gè)連接的讀寫操作在同一個(gè)循環(huán)里分批執(zhí)行減少了系統(tǒng)調(diào)用次數(shù)和鎖競(jìng)爭(zhēng)。這些都是標(biāo)準(zhǔn)庫(kù)很難做到的數(shù)據(jù)面自由度。3. 從系統(tǒng)調(diào)用到事件循環(huán)的完整鏈路3.1 epoll 的三板斧create、ctl、wait在 Linux 上epoll 的使用套路非常固定。首先epoll_create1創(chuàng)建 epoll 實(shí)例然后epoll_ctl把一個(gè) fd 和關(guān)注的事件類型EPOLLIN、EPOLLOUT、EPOLLET 等綁定到實(shí)例上之后反復(fù)調(diào)用epoll_wait獲取已經(jīng)就緒的事件列表。netpoll 的 Poller 層會(huì)把這三步全部封裝成方法Open()負(fù)責(zé)創(chuàng)建 epoll fdControl()負(fù)責(zé)添加/修改/刪除注冊(cè)事件Wait()負(fù)責(zé)阻賽等待并返回事件數(shù)組。它返回的事件數(shù)組不是簡(jiǎn)單地給用戶一個(gè)整數(shù)掩碼而是打包好一個(gè)event結(jié)構(gòu)里面包含 fd、事件類型方便上層 HashMap 直接找到對(duì)應(yīng)的連接。這里有一個(gè)值得注意的細(xì)節(jié)netpoll 在網(wǎng)絡(luò)事件處理上做了“事件驅(qū)動(dòng)”和“非阻塞”的結(jié)合。注冊(cè)的 fd 默認(rèn)都是非阻塞模式這樣在epoll_wait返回說(shuō)“可讀”之后你調(diào)用read即使沒(méi)能一次讀完也不會(huì)把 goroutine 卡死而是借用內(nèi)部緩沖繼續(xù)循環(huán)讀直到返回EAGAIN再停手。3.2 EventLoop 的輪詢循環(huán)內(nèi)部長(zhǎng)什么樣看 netpoll 的核心循環(huán)大致可以拆成這幾步// 這是我對(duì) netpoll 主循環(huán)的示意細(xì)節(jié)以源碼為準(zhǔn) for { events : poller.Wait() for _, ev : range events { conn : connectionMap[ev.Fd] if ev.Readable { conn.HandleRead() } if ev.Writable { conn.HandleWrite() } if ev.Error { conn.Close() } } }這段邏輯看著樸素的像偽代碼但它其實(shí)是整個(gè)模型的心臟。poller.Wait()會(huì)阻塞直到內(nèi)核告訴它有事件拿到事件列表之后直接根據(jù) fd 找到連接對(duì)象按事件類型分發(fā)處理。事件處理是同步的好處是天然線程安全不需要為每個(gè)連接加鎖壞處是單個(gè)回調(diào)太慢會(huì)拖累整個(gè)事件循環(huán)。所以 netpoll 對(duì)用戶的OnRequest回調(diào)有明確建議不要在里面做重計(jì)算、不要調(diào)用阻塞 I/O。如果你確實(shí)有耗時(shí)的業(yè)務(wù)邏輯應(yīng)該在回調(diào)里把數(shù)據(jù) copy 出來(lái)丟到別的 goroutine 里去處理。這個(gè)約束是所有事件驅(qū)動(dòng)模型必須遵守的netty 有pipeline的線程模型netpoll 也有類似的邊界。3.3 事件緩沖區(qū)的巧妙之處每次epoll_wait都可能返回成百上千個(gè)就緒事件。如果每次等待都去make一個(gè)數(shù)組在高頻事件下 GC 壓力會(huì)很大。netpoll 的 Poller 在初始化時(shí)就會(huì)準(zhǔn)備一塊足夠大的事件緩沖數(shù)組并且每次Wait之后會(huì)復(fù)用這塊內(nèi)存只更新len。這樣既避免了頻繁分配又減少了 GC。這塊緩沖設(shè)計(jì)我在代碼里看到時(shí)是有點(diǎn)驚訝的它顯然從 Netty 那里學(xué)了不少。Netty 里叫epollEventArraynetpoll 里也是類似思路——一個(gè)[]epoll.Event的容器容量默認(rèn)可能開到MaxEventsPerLoop在線程/goroutine 內(nèi)部循環(huán)利用。這也提醒我們寫高性能網(wǎng)絡(luò)庫(kù)時(shí)“對(duì)象復(fù)用”和“池化”是繞不開的話題。另外epoll_wait的 timeout 參數(shù)在 netpoll 里也不是隨便設(shè)的。如果設(shè)置 too large可能會(huì)拖慢連接關(guān)閉、退出事件循環(huán)的響應(yīng)速度如果設(shè) too smallCPU 空轉(zhuǎn)又明顯。我看到 netpoll 在等待時(shí)采用了可變的 timeout 策略大致是“長(zhǎng)時(shí)間沒(méi)有事件時(shí)用較大 timeout事件密集時(shí)退避到較小 timeout”類似 Nginx 的 ngx_event 里對(duì) timer 的處理。這么做既保證低延遲又不會(huì)白白空轉(zhuǎn)燒 CPU。4. 連接狀態(tài)的流轉(zhuǎn)與讀寫緩沖設(shè)計(jì)4.1 連接狀態(tài)機(jī)從 Init 到 Closed學(xué)過(guò) TCP 狀態(tài)機(jī)的人應(yīng)該很熟悉網(wǎng)絡(luò)庫(kù)里“連接要有狀態(tài)”的思路。netpoll 里的連接對(duì)象也維護(hù)了一個(gè)狀態(tài)機(jī)主要狀態(tài)大致是Init連接對(duì)象剛創(chuàng)建還沒(méi)開始注冊(cè)事件Connectedfd 已注冊(cè)到 poller可以正常讀寫Closing/Closed表示連接正在關(guān)閉或已經(jīng)關(guān)閉。狀態(tài)機(jī)的價(jià)值在于約束操作。比如Write()如果發(fā)生在Closed狀態(tài)就不能再去碰 fd 了比如讀事件回調(diào)發(fā)現(xiàn)連接已經(jīng)被業(yè)務(wù)方 close 了就不能再去調(diào)用 HandleRead。實(shí)際源碼里經(jīng)常能看到atomic.StoreInt32(c.state, ...)這種操作因?yàn)檫B接對(duì)象可能被多個(gè) loop 或者多個(gè) goroutine 同時(shí)訪問(wèn)只有使用原子操作才能保證狀態(tài)可見性。我做連接池的時(shí)候吃過(guò)這個(gè)虧沒(méi)有狀態(tài)機(jī)直接判斷conn ! nil就復(fù)用結(jié)果在極端關(guān)閉時(shí)間點(diǎn)出現(xiàn)“fd 已經(jīng)被 epoll 移除但對(duì)象還被復(fù)用”的競(jìng)態(tài)線上出現(xiàn)莫名其妙的errno 9: Bad file descriptor。后來(lái)看了 netpoll 對(duì)連接的封裝發(fā)現(xiàn)它對(duì)狀態(tài)控制的粒度很細(xì)比如寫操作會(huì)先檢查isActive再檢查緩沖區(qū)是否有舊數(shù)據(jù)最后才決定要不要注冊(cè)寫事件。這個(gè)順序很重要反過(guò)來(lái)很容易出現(xiàn)“注冊(cè)了寫事件但緩沖區(qū)是空的”這種空轉(zhuǎn)事件。4.2 讀流程非阻塞讀到 EAGAIN 為止讀事件觸發(fā)后netpoll 會(huì)嘗試把 fd 里的數(shù)據(jù)盡量讀出來(lái)。它內(nèi)部維護(hù)了一個(gè)輸入緩沖區(qū)InputBuffer讀到的數(shù)據(jù)先append到緩沖區(qū)里然后觸發(fā)OnRequest之類的回調(diào)讓你消費(fèi)緩沖區(qū)里的數(shù)據(jù)。為什么非要“讀到 EAGAIN 為止”因?yàn)?epoll 是水平觸發(fā)的話如果你不讀完下次epoll_wait還會(huì)繼續(xù)上報(bào)可讀事件會(huì)造成重復(fù)通知。netpoll 默認(rèn)使用 LT 還是 ET 我不展開討論重要的是非阻塞讀加一個(gè)大一點(diǎn)的緩沖區(qū)可以避免反復(fù) wakeup提升吞吐。反過(guò)來(lái)如果一次只讀一點(diǎn)數(shù)據(jù)就交給業(yè)務(wù)每次事件只能消費(fèi)一點(diǎn)事件通知次數(shù)會(huì)成倍增加效率自然難看。讀緩沖區(qū)的增長(zhǎng)策略也需要關(guān)注。連接剛建立時(shí)通常會(huì)給一個(gè)較小的初始 buffer比如 2KB 或 4KB之后按需擴(kuò)容。netpoll 里 buffer 部分直接引用了runtime的growslice思想擴(kuò)容時(shí)按倍數(shù)擴(kuò)大避免頻繁 copy。我在用標(biāo)準(zhǔn)庫(kù)bufio.Reader時(shí)也愛用大一點(diǎn)的初始化 size本質(zhì)原因都一樣。4.3 寫流程寫緩沖合并與事件注冊(cè)寫路徑比讀路徑更繞。業(yè)務(wù)方調(diào)用Write()時(shí)數(shù)據(jù)其實(shí)不是直接進(jìn)內(nèi)核發(fā)送而是先寫到連接的輸出緩沖區(qū)OutputBuffer。之后 netpoll 會(huì)根據(jù) fd 的當(dāng)前狀態(tài)決定如果 fd 當(dāng)前可寫就直接嘗試 flush 緩沖區(qū)如果上一次還有沒(méi)發(fā)完的數(shù)據(jù)就在 poller 上注冊(cè) EPOLLOUT 事件等著內(nèi)核通知可寫再繼續(xù)發(fā)。這里有個(gè)細(xì)節(jié)EPOLLOUT事件不是一直注冊(cè)著的因?yàn)榇蟛糠謺r(shí)間連接都是可寫的注冊(cè)了反而會(huì)頻繁觸發(fā)“可寫”事件造成忙輪詢。netpoll 的做法是延遲到“確實(shí)有寫不出去的數(shù)據(jù)”時(shí)才注冊(cè)寫事件。這個(gè)設(shè)計(jì)我很認(rèn)同相當(dāng)于把最昂貴的epoll_ctl系統(tǒng)調(diào)用次數(shù)壓縮到了最少。另外寫緩沖合并也是 netpoll 降低系統(tǒng)調(diào)用量的手段。比如業(yè)務(wù)連續(xù)兩次Write()如果前后間隔極短netpoll 可以先合并在同一個(gè)用戶態(tài)緩沖區(qū)里再一次writev發(fā)出去。這活兒看起來(lái)簡(jiǎn)單實(shí)際上要處理“并發(fā)寫鎖”和“緩沖區(qū)游標(biāo)”的問(wèn)題做差了容易丟數(shù)據(jù)或者亂序。4.4 內(nèi)存復(fù)用與池化高并發(fā)網(wǎng)絡(luò)庫(kù)里內(nèi)存分配是性能大頭之一。每次都從堆上 make 一個(gè) bytes slice 用來(lái)裝網(wǎng)絡(luò)數(shù)據(jù)沒(méi)有池化GC 壓力會(huì)巨大。netpoll 在緩沖池這塊下了不少功夫?qū)ψx緩沖、寫緩沖都做了復(fù)用。簡(jiǎn)單說(shuō)就是連接關(guān)閉后它的輸出緩沖和讀緩沖對(duì)象可以放回池子里新連接創(chuàng)建時(shí)再掏出來(lái)用省掉了反復(fù)malloc的開銷。我看 pprof 數(shù)據(jù)時(shí)特別喜歡關(guān)注runtime.mallocgc的占比。用標(biāo)準(zhǔn)庫(kù)寫網(wǎng)絡(luò)服務(wù)malloc 占比經(jīng)常在 15%~25% 之間徘徊換到 netpoll 加連接池這個(gè)數(shù)字能壓到 10% 以下。這不僅僅是框架的功勞和業(yè)務(wù)側(cè)盡量復(fù)用 []byte 也有關(guān)系。框架能幫你做的只是減少“連接級(jí)緩沖”的分配業(yè)務(wù)回調(diào)里如果每次都append出新的 sliceGC 還是躲不掉。5. 高性能的關(guān)鍵批量、零拷貝與多路復(fù)用5.1 用 readv 聚合多個(gè)緩沖區(qū)readv是 Linux 提供的一個(gè)系統(tǒng)調(diào)用它允許一次 read 操作把數(shù)據(jù)寫到多個(gè)內(nèi)存塊中。netpoll 在讀事件里可以使用readv把數(shù)據(jù)分別讀到“read buffer 的剩余空間”和“額外準(zhǔn)備的輔助 buffer”中這樣即使 fd 上的數(shù)據(jù)比當(dāng)前緩沖剩余空間還多也能一次性拿到更多數(shù)據(jù)減少系統(tǒng)調(diào)用次數(shù)。這個(gè)操作對(duì)“一次事件處理盡量多收數(shù)”特別有效。普通read可能一次只能搬到大小為 4KB 的緩沖區(qū)然后發(fā)現(xiàn)還有數(shù)據(jù)又要再 read 一次readv則可以只調(diào)用一次內(nèi)核先把填充當(dāng)前 buffer再把剩下的數(shù)據(jù)填充到第二個(gè) buffer系統(tǒng)調(diào)用次數(shù)能省一半以上。netpoll 一般在 buffer 不足時(shí)會(huì)走這個(gè)邏輯但是具體觸發(fā)條件需要看代碼里對(duì)Grow策略的設(shè)計(jì)。我自己的實(shí)踐體會(huì)是大包場(chǎng)景下 readv 收益非常明顯小包場(chǎng)景下效果平平因?yàn)橄到y(tǒng)調(diào)用次數(shù)大頭主要在事件本身而不是 read 次數(shù)。5.2 writev 聚合小包發(fā)送對(duì)應(yīng)的寫側(cè)有writev一次調(diào)用可以把多個(gè)內(nèi)存塊的數(shù)據(jù)順序發(fā)送到內(nèi)核。netpoll 的寫緩沖結(jié)構(gòu)天然適合配合 writev輸出緩沖區(qū)可能殘留之前的半截?cái)?shù)據(jù)業(yè)務(wù)又追加了新的數(shù)據(jù)這兩段數(shù)據(jù)不連續(xù)但用 writev 可以一次發(fā)出。小包聚合對(duì) RPC 框架來(lái)說(shuō)尤其重要。微服務(wù)一次請(qǐng)求/響應(yīng)體量通常只有幾百字節(jié)到幾 KB如果每個(gè)包都立刻發(fā)送TCP 層面會(huì)釋放大量小包網(wǎng)絡(luò)棧消耗很高。netpoll 在寫路徑上通常會(huì)有“延遲 flush”或者“批量 flush”的取舍不過(guò)需要小心過(guò)度合并會(huì)增大消息延遲尤其對(duì)首包延遲敏感的服務(wù)不是好事。我在壓測(cè)時(shí)觀察過(guò)開啟小包合并且觸發(fā)條件設(shè)置合理時(shí)CPU 的 sys 占比能降低 3~5 個(gè)百分點(diǎn)。代價(jià)是單條消息的 p99 延遲可能從 0.5ms 漲到 1ms 左右。所以“要不要合并”要結(jié)合業(yè)務(wù) SLA 去權(quán)衡不是一味追求聚合就好。5.3 零拷貝與 sendfile 的適用邊界很多文章一提到高性能網(wǎng)絡(luò)庫(kù)就要聊零拷貝。netpoll 里對(duì) sendfile 這類機(jī)制有所涉及主要場(chǎng)景是服務(wù)端向客戶端發(fā)送文件數(shù)據(jù)比如靜態(tài)資源服務(wù)。通過(guò)sendfile系統(tǒng)調(diào)用可以直接把文件內(nèi)容從內(nèi)核頁(yè)緩存發(fā)送到 socket不需要把數(shù)據(jù)從內(nèi)核拷貝到用戶態(tài)也不需要用戶態(tài)再拷到 socket buffer。但注意RPC 場(chǎng)景下絕大多數(shù)消息是業(yè)務(wù)生成的響應(yīng)體不在文件里所以 sendfile 的適用場(chǎng)景沒(méi)想象中那么大。真正在 RPC 數(shù)據(jù)路徑上發(fā)力的還是“減少用戶態(tài)和內(nèi)核態(tài)之間無(wú)意義的拷貝次數(shù)”也就是盡量復(fù)用緩沖、避免業(yè)務(wù)層 copy。netpoll 的緩沖設(shè)計(jì)讓 OnRequest 回調(diào)拿到的 []byte 可以在業(yè)務(wù)處理完之后直接把同一個(gè)底層數(shù)組用于響應(yīng)不需要多余的拷貝這種情況下比標(biāo)準(zhǔn)庫(kù)的多次 copy 要省。關(guān)于splice它也是零拷貝的一種方式但復(fù)雜度更高我見過(guò)不少團(tuán)隊(duì)在 TCP 代理場(chǎng)景里想用 splice最后因?yàn)檫吔鐥l件處理太復(fù)雜放棄了。netpoll 官方也沒(méi)有把它作為核心特性更多還是依賴 readv/writev 加緩沖池來(lái)達(dá)到性能目標(biāo)。5.4 減少 epoll_ctl 的調(diào)用次數(shù)epoll_ctl 是系統(tǒng)調(diào)用不能隨便打尤其是高并發(fā)下早于事件通知而反復(fù)修改監(jiān)聽事件會(huì)帶來(lái)巨大的用戶態(tài)與內(nèi)核態(tài)切換開銷。netpoll 在這方面做了很多優(yōu)化比如寫事件延遲注冊(cè)、讀事件盡量常駐監(jiān)聽、通過(guò) update 事件掩碼來(lái)避免刪除再添加。有一點(diǎn)讓我印象很深它把“fd 是否需要注冊(cè)寫事件”的判斷放到了寫路徑的末尾而不是每次 Write 都調(diào) epoll_ctl。這樣做的目的在于把 epoll_ctl 的調(diào)用頻次從“每次業(yè)務(wù)寫”降低到“每次遇到寫阻塞”。系統(tǒng)調(diào)用頻次的優(yōu)化在高 QPS 服務(wù)下關(guān)系重大每次 syscall 即便只有 1~2 微秒峰值時(shí)也會(huì)迅速疊加成可觀的 CPU 消耗。6. 用 netpoll 寫一個(gè)最小服務(wù)以及源碼閱讀路線6.1 五步搭一個(gè) echo server單純看模型容易飄上手跑一個(gè)例子理解最快。netpoll 的應(yīng)用層 API 非常簡(jiǎn)潔一個(gè)最小 echo server 大概是這樣的package main import ( context fmt github.com/cloudwego/netpoll ) func main() { eventLoop, err : netpoll.NewEventLoop(func(ctx context.Context, connection netpoll.Connection) error { // 讀取連接上當(dāng)前可讀的所有數(shù)據(jù) reader : connection.Reader() data : make([]byte, reader.Len()) _, _ reader.Read(data) // 原樣寫回去 writer : connection.Writer() _ writer.WriteBinary(data) return writer.Flush() }) if err ! nil { panic(err) } err eventLoop.Serve(netpoll.NewListener(tcp, :8080)) if err ! nil { fmt.Println(serve error:, err) } }這段代碼的處理邏輯是這樣的注冊(cè)一個(gè)OnRequest回調(diào)連接有數(shù)據(jù)可讀時(shí)框架會(huì)Read出來(lái)拼接到reader里然后你從reader里把數(shù)據(jù)拿出來(lái)再通過(guò)writer寫回。Flush()是真正觸發(fā)底層寫路徑的入口它會(huì)把輸出緩沖區(qū)交給連接去 flush。從這個(gè)小例子能看到兩層結(jié)構(gòu)事件循環(huán)層EventLoop.Serve負(fù)責(zé)接收連接和分發(fā)事件連接層Connection負(fù)責(zé)提供 Reader/Writer 這樣的流式讀寫接口。實(shí)際項(xiàng)目中我建議把 OnRequest 中間的 copy 去掉而是直接復(fù)用 netpoll 的連接緩沖來(lái)構(gòu)造響應(yīng)。因?yàn)樵?baseline 上每個(gè)請(qǐng)求都make([]byte, reader.Len())的話GC 很快會(huì)把你辛苦省下來(lái)的性能又還回去。6.2 常用配置項(xiàng)說(shuō)明netpoll 的配置項(xiàng)不算多但每一個(gè)都值得調(diào)優(yōu)時(shí)有意識(shí)地去改。我用的比較頻繁的幾個(gè)WithNumLoops指定 event loop 數(shù)量一般等于 CPU 核數(shù)。WithReadTimeout連接讀超時(shí)超時(shí)連接會(huì)被框架關(guān)閉。WithWriteTimeout寫超時(shí)對(duì)異常連接的兜底非常重要。WithIdleTimeout空閑連接超時(shí)常用于服務(wù)端主動(dòng)淘汰不再活躍的連接。在這些參數(shù)里我最關(guān)注WithIdleTimeout。很多長(zhǎng)連接服務(wù)會(huì)把空閑連接一直放著不管時(shí)間一長(zhǎng)服務(wù)端 fd 數(shù)量不斷攀升最終觸發(fā)too many open files。netpoll 提供了這個(gè)參數(shù)可以方便地清理閑置連接但設(shè)得太短會(huì)把一些低頻但正常的連接誤殺所以經(jīng)驗(yàn)值是結(jié)合業(yè)務(wù)?；顧C(jī)制比如心跳間隔去設(shè)置一般設(shè)為心跳間隔的 2~3 倍。6.3 源碼閱讀建議如果你想深入源碼我建議不要從最外層EventLoop開始讀那樣容易被大量封裝干擾。我的閱讀路徑是先看netpoll/polling包了解 epoll/kqueue 的封裝這是整個(gè)模型的地基再看netpoll/connection包重點(diǎn)看Connection的讀寫緩沖、事件注冊(cè)、狀態(tài)流轉(zhuǎn)最后回到netpoll/eventloop包看它怎么把連接注冊(cè)到 poller、如何在 loop 循環(huán)里分發(fā)事件。閱讀時(shí)盯住三個(gè)核心行為HandleRead、HandleWrite、Close。把這三個(gè)方法看懂了整個(gè) netpoll 的網(wǎng)絡(luò)生命周期就通了。那些關(guān)于 buffer 的零碎代碼可以在有性能調(diào)優(yōu)需求時(shí)再回頭細(xì)看。另外閱讀時(shí)最好用 Linux 環(huán)境因?yàn)?kqueue 分支和 epoll 分支多少有點(diǎn)差異Linux 是最常用的生產(chǎn)環(huán)境理解 epoll 路徑收益最大。7. 線上踩坑與排查經(jīng)驗(yàn)實(shí)錄7.1 回調(diào)里做耗時(shí)操作整個(gè) loop 都被拖垮事件驅(qū)動(dòng)模型最大的坑就是這個(gè)。某個(gè)連接的 OnRequest 里如果做了一次較慢的 DB 查詢比如 50ms那同一 EventLoop 上其他所有連接的事件都會(huì)排在這 50ms 之后。結(jié)果就是“一個(gè)連接慢拖垮一批連接”現(xiàn)象經(jīng)常是部分請(qǐng)求的延遲突然拉高。排查方法很直接在 OnRequest 入口和出口打點(diǎn)看單次回調(diào)耗時(shí)的 p99。如果發(fā)現(xiàn)回調(diào)本身耗時(shí)過(guò)高就要把業(yè)務(wù)邏輯拆出去用 goroutine 并發(fā)處理。數(shù)據(jù)要特別注意netpoll 的 Reader 是連接緩沖跨 goroutine 使用前必須先 copy 出來(lái)否則緩沖被后續(xù)事件復(fù)用后數(shù)據(jù)就亂了。提示OnRequest 回調(diào)應(yīng)該是“純網(wǎng)絡(luò)數(shù)據(jù)處理邏輯”任何 I/O 等待、鎖等待、重量級(jí)計(jì)算都應(yīng)該放到回調(diào)外的 goroutine 里去做。7.2 連接泄漏與 fd 耗盡用 netpoll 后連接數(shù)不等于 goroutine 數(shù)所以連接泄漏更隱蔽。fd 耗盡時(shí)服務(wù)表現(xiàn)是新建連接失敗Accept報(bào)EMFILE但存量請(qǐng)求看起來(lái)還正常。這時(shí)候一般是被某個(gè)業(yè)務(wù)邏輯忘記 Close 連接了。我遇到過(guò)一次比較隱蔽的情況客戶端的連接異常斷開后服務(wù)端沒(méi)有及時(shí)感知因?yàn)閼?yīng)用層沒(méi)有設(shè)置讀寫超時(shí)。內(nèi)核可能在很長(zhǎng)時(shí)間后才發(fā)出 FIN/RST期間這條半開連接一直占著 fd。解決辦法有兩步一是設(shè)置合理的ReadTimeout或IdleTimeout二是在 OnRequest 里針對(duì)協(xié)議心跳做校驗(yàn)連續(xù) N 次心跳超時(shí)主動(dòng)關(guān)閉連接。排查 fd 泄漏可以用lsof -p pid | wc -l快速看數(shù)量如果持續(xù)增長(zhǎng)再通過(guò)strace -p pid -f -e traceaccept4,close看系統(tǒng)調(diào)用的 accept 和 close 頻率基本能定位到漏掉的 Close。7.3 Nagle 算法與 TCP_NODELAY 的微妙關(guān)系Go 標(biāo)準(zhǔn)庫(kù)默認(rèn)會(huì)把 TCP_NODELAY 打開也就是禁用 Nagle 算法保證小包不延遲。netpoll 繼承了這一點(diǎn)默認(rèn)連接都是 NODELAY。但有次我遇到一個(gè)問(wèn)題服務(wù)某條鏈路的延遲偶發(fā)跳到幾十毫秒排查很久發(fā)現(xiàn)是我們自己的網(wǎng)關(guān)層在“收到響應(yīng)后不立刻 flush而是等下一波事件時(shí)再 flush”和 Nagle 無(wú)關(guān)屬于業(yè)務(wù)緩沖策略過(guò)度。這類問(wèn)題提醒我寫完業(yè)務(wù)代碼后要關(guān)注 writer.Flush 的觸發(fā)時(shí)機(jī)。如果你在回調(diào)里只 Write 不 Flush數(shù)據(jù)會(huì)一直積壓在用戶態(tài)緩沖里看起來(lái)像網(wǎng)絡(luò)延遲實(shí)際是框架還沒(méi)把數(shù)據(jù)發(fā)給內(nèi)核。正確做法是確定當(dāng)前處理邏輯完成后立刻 Flush除非你有明確的批量化意圖。7.4 低并發(fā)小場(chǎng)景下netpoll 可能反而不值得netpoll 不是銀彈。如果你的服務(wù)連接數(shù)只有幾百請(qǐng)求頻率不高標(biāo)準(zhǔn)庫(kù)的 goroutine-per-conn 模型寫起來(lái)簡(jiǎn)單維護(hù)性也更好性能差異在低并發(fā)下微乎其微。強(qiáng)行上 netpoll反而要處理回調(diào)限制、緩沖生命周期、事件循環(huán)阻塞這些復(fù)雜問(wèn)題。我見過(guò)一個(gè)團(tuán)隊(duì)在內(nèi)部管理系統(tǒng)的上報(bào)接口里強(qiáng)行引入 netpoll最后寫出來(lái)的代碼比標(biāo)準(zhǔn)庫(kù)復(fù)雜得多性能收益卻幾乎沒(méi)有。高性能方案是有成本的只有連接規(guī)模大到標(biāo)準(zhǔn)庫(kù)模型開始難受時(shí)netpoll 才真正體現(xiàn)價(jià)值。這也算是我這幾年做技術(shù)選型的一個(gè)原則先用量化指標(biāo)確認(rèn)瓶頸再?zèng)Q定是否引入更復(fù)雜的模型。7.5 注意與 Go runtime 調(diào)度器的邊界Go 本身有 goroutine 和 runtime schedulernetpoll 的事件循環(huán)也是跑在 goroutine 上的。這帶來(lái)一個(gè)問(wèn)題事件循環(huán) goroutine 如果頻繁被 Go runtime 調(diào)度走比如其他 goroutine 大量占 CPU網(wǎng)絡(luò)事件處理的實(shí)時(shí)性會(huì)受影響。雖然 Go 的調(diào)度器在 GMP 模型下已經(jīng)盡量降低這種影響但極端情況下比如某個(gè) goroutine 進(jìn)入runtime.LockOSThread長(zhǎng)時(shí)間持有線程事件循環(huán)的調(diào)度還是會(huì)出現(xiàn)卡頓。所以在部署 netpoll 服務(wù)時(shí)我會(huì)盡量保持 CPU 負(fù)載在 70% 以下避免調(diào)度器為了搶 CPU 產(chǎn)生顯著抖動(dòng)。同時(shí)把GOMAXPROCS設(shè)置成容器/機(jī)器的物理核數(shù)不要盲目調(diào)大否則事件循環(huán) goroutine 多了反而增加調(diào)度開銷。最后分享一點(diǎn)我的實(shí)際體會(huì)這個(gè)模型我在生產(chǎn)環(huán)境跑了快兩年從一開始把 netpoll 當(dāng)性能銀彈到后來(lái)慢慢理解它是為某個(gè)特定場(chǎng)景大規(guī)模長(zhǎng)連接、低延遲 RPC而生的中間走了不少?gòu)澛贰，F(xiàn)在我做技術(shù)方案時(shí)會(huì)先想清楚三個(gè)問(wèn)題連接數(shù)大概多少消息大小分布如何延遲要求多嚴(yán)格這三個(gè)問(wèn)題答案不同選型就完全不一樣。netpoll 讓我最佩服的地方不是某個(gè)單一系統(tǒng)調(diào)用而是它對(duì)整個(gè)網(wǎng)絡(luò)數(shù)據(jù)路徑的精細(xì)化控制事件循環(huán)、緩沖池、系統(tǒng)調(diào)用聚合、狀態(tài)機(jī)。這些點(diǎn)單獨(dú)看都不算難但組合在一起就成了一個(gè)能打高并發(fā)的工業(yè)級(jí)網(wǎng)絡(luò)庫(kù)。如果你也在做 Go 網(wǎng)絡(luò)服務(wù)我建議先跑一跑它官方的 benchmark再對(duì)照 pprof 看自己的瓶頸點(diǎn)到底在哪里然后決定要不要把模型切過(guò)去。這比聽我說(shuō)一百句“它很高效”都要有用。 Go 高性能網(wǎng)絡(luò)庫(kù) netpoll：事件驅(qū)動(dòng)模型與 Reactor 工程實(shí)踐
如果你用Go寫過(guò)面向高并發(fā)的網(wǎng)絡(luò)服務(wù)一定經(jīng)歷過(guò)這樣的階段一開始標(biāo)準(zhǔn)庫(kù)的net包用得很爽Accept 一個(gè)連接就go一個(gè) goroutine代碼簡(jiǎn)單到不行。等連接數(shù)從幾百漲到幾萬(wàn)goroutine 數(shù)量、內(nèi)存占用、上下文切換一起爆炸CPU profiling 一看調(diào)度器的負(fù)擔(dān)比業(yè)務(wù)代碼還重。這時(shí)候再去搜索 Go 網(wǎng)絡(luò)性能優(yōu)化的方案大概率會(huì)看到一個(gè)名字netpoll。netpoll 是字節(jié)跳動(dòng)開源的高性能網(wǎng)絡(luò)庫(kù)最初是為 Kitex 這類微服務(wù) RPC 框架服務(wù)的。它底層走的是事件驅(qū)動(dòng)模型核心思路和 Redis、Netty 是一路的用少量線程/協(xié)程管理海量連接連接來(lái)了不分配 goroutine而是注冊(cè)事件真正有數(shù)據(jù)可讀可寫時(shí)才觸發(fā)處理。這篇博客我會(huì)站在從業(yè)者的角度把 netpoll 的模型拆開講清楚包括它解決什么問(wèn)題、事件循環(huán)如何工作、連接狀態(tài)怎么流轉(zhuǎn)以及在實(shí)際項(xiàng)目中應(yīng)該怎么用、踩過(guò)哪些坑。無(wú)論你是剛開始看 Go 網(wǎng)絡(luò)編程還是想拿它優(yōu)化自己的 RPC 服務(wù)這篇文章都值得讀完。1. 為什么需要 netpoll 這樣的網(wǎng)絡(luò)模型1.1 標(biāo)準(zhǔn)庫(kù)網(wǎng)絡(luò)模型的天花板在哪里Go 標(biāo)準(zhǔn)庫(kù)的net包在底層其實(shí)已經(jīng)封裝了 epoll/kqueue通過(guò)runtime netpoller實(shí)現(xiàn)了非阻塞 I/O所以標(biāo)準(zhǔn)庫(kù)寫并發(fā)網(wǎng)絡(luò)服務(wù)并不笨。真正的問(wèn)題出在編程模型上標(biāo)準(zhǔn)庫(kù)給到用戶的 API 是“每個(gè)連接一個(gè) goroutine”你用Accept()拿回一個(gè)net.Conn之后想讀想寫直接conn.Read()、conn.Write()就行庫(kù)會(huì)自動(dòng)幫你把 fd 注冊(cè)到全局的網(wǎng)絡(luò)輪詢器中。這個(gè)模型寫起來(lái)很爽但代價(jià)是一個(gè)連接對(duì)應(yīng)一個(gè)常駐 goroutine。連接數(shù)是幾千的時(shí)候還沒(méi)啥感覺(jué)到了十萬(wàn)、百萬(wàn)連接的時(shí)候光 goroutine 的棧內(nèi)存就可能占掉幾百 MB再加上 goroutine 的創(chuàng)建銷毀、調(diào)度器要頻繁切換運(yùn)行隊(duì)列CPU 白白燒掉的太多了。我做過(guò)一個(gè)壓測(cè)同樣一臺(tái) 8C16G 的機(jī)器用標(biāo)準(zhǔn)庫(kù)的net/http寫長(zhǎng)連接服務(wù)連接數(shù)到了 5 萬(wàn)左右goroutine 數(shù)直接沖到 5 萬(wàn)pprof 里看runtime.futex、runtime.schedule的開銷已經(jīng)排到了前幾名。業(yè)務(wù)邏輯其實(shí)很簡(jiǎn)單但調(diào)度和內(nèi)存占用反客為主了。這就是標(biāo)準(zhǔn)庫(kù)模型的第一個(gè)天花板goroutine-per-connection 在連接數(shù)極高時(shí)goroutine 本身成了資源瓶頸。第二個(gè)天花板是標(biāo)準(zhǔn)庫(kù)把底層細(xì)節(jié)封得太死了。你拿到的是一根net.Conn管道它不會(huì)告訴你這個(gè) fd 是不是真的可寫了也不會(huì)給你機(jī)會(huì)批量處理同一次epoll_wait返回的多組事件。標(biāo)準(zhǔn)庫(kù)內(nèi)部的poll.FD是給runtime netpoller用的暴露出來(lái)的接口非常有限你想做更精細(xì)的調(diào)度、想用readv批量接收多個(gè) buffer根本沒(méi)有入口。第三個(gè)天花板是標(biāo)準(zhǔn)庫(kù)的緩沖策略。net.Conn底層的讀緩沖是有限度的TCP 包來(lái)一個(gè)你Read拿走一個(gè)每次 Read 都可能是用戶態(tài)到內(nèi)核態(tài)的一次邊界。對(duì)延遲特別敏感、小包特別多的 RPC 場(chǎng)景來(lái)說(shuō)這種粒度有點(diǎn)粗。1.2 netpoll 的定位從連接模型改為事件模型netpoll 的思路很簡(jiǎn)單把“一個(gè)連接一個(gè) goroutine”改成“一個(gè)事件循環(huán)管一堆連接”。它復(fù)用 epoll/kqueue 的能力讓事件循環(huán)去epoll_wait等具體某個(gè) fd 可讀、可寫時(shí)才回調(diào)處理邏輯。這樣連接數(shù)再多處理這些連接的 goroutine 數(shù)量也是固定的通常等于 CPU 核數(shù)。這種模型最大的優(yōu)勢(shì)在于高連接數(shù)下不會(huì)再有大量 goroutine 被Read阻塞在那里。每個(gè)連接在相安無(wú)事時(shí)只是一個(gè)注冊(cè)在 epoll 里的 fd加一個(gè) connection 對(duì)象若干緩沖區(qū)。CPU 只在真正有數(shù)據(jù)流動(dòng)時(shí)才被喚醒空閑連接幾乎不消耗 CPU 和內(nèi)存。拿我線上一個(gè)實(shí)際例子來(lái)說(shuō)一個(gè)對(duì)外提供長(zhǎng)連接推送的服務(wù)改造前用標(biāo)準(zhǔn)庫(kù)連接峰值 3 萬(wàn)內(nèi)存穩(wěn)定在 1.2GB 左右換成 netpoll 模型之后同樣 3 萬(wàn)連接內(nèi)存降到 400MB 出頭CPU 占用大約低了 30%。原因就是不再為每個(gè)連接保留一個(gè)阻塞著的 goroutine那些 goroutine 的棧、上下文信息就全省下來(lái)了。netpoll 并不是要替代標(biāo)準(zhǔn)庫(kù)在“低并發(fā)、高開發(fā)效率”場(chǎng)景下的地位。它是為解決“海量連接 低延遲 RPC 可控資源”這個(gè)問(wèn)題而生的所以在微服務(wù)框架里應(yīng)用最廣。如果你也在做 RPC、網(wǎng)關(guān)、長(zhǎng)連接推送理解 netpoll 的模型是很有價(jià)值的。2. 核心設(shè)計(jì)事件驅(qū)動(dòng)與 Reactor 模型的工程化落地2.1 事件驅(qū)動(dòng)模型的基本思路事件驅(qū)動(dòng)模型本質(zhì)上是一個(gè)無(wú)限循環(huán)等事件 - 分發(fā)事件 - 處理事件 - 再等事件。對(duì)網(wǎng)絡(luò)層來(lái)說(shuō)這個(gè)“事件”通常就是某個(gè) fd 可讀、可寫、出錯(cuò)。epoll 的作用就是把“操心哪個(gè) fd 有動(dòng)靜”這個(gè)活兒交給內(nèi)核用戶程序只需要epoll_wait阻塞等結(jié)果。netpoll 在這個(gè)基礎(chǔ)上做了一層很細(xì)的封裝。注意Go 里貼到應(yīng)用層的“goroutine”概念和操作系統(tǒng)線程不完全等價(jià)所以 netpoll 的事件循環(huán)并不是說(shuō)每個(gè)循環(huán)綁死一個(gè) OS 線程它還是依托 goroutine 調(diào)度。但它在應(yīng)用層做了一個(gè)“由事件循環(huán)統(tǒng)一 poll fd”的抽象把網(wǎng)絡(luò)事件和用戶業(yè)務(wù)回調(diào)解耦開。我理解 netpoll 的核心抽象分三層EventLoop對(duì)外暴露的事件循環(huán)負(fù)責(zé)啟動(dòng)、停止、注冊(cè)連接Poller對(duì) epoll/kqueue 的封裝負(fù)責(zé)create,ctl,wait這類系統(tǒng)操作Connection一個(gè)連接對(duì)象的抽象包含 fd、讀寫緩沖區(qū)、狀態(tài)、回調(diào)。這種分層我在讀源碼時(shí)感覺(jué)很舒服因?yàn)槊恳粚佣伎梢詥为?dú)替換。例如 Poller 層Linux 上走 epollmacOS/BSD 上走 kqueue業(yè)務(wù)代碼感知不到這就是抽象的價(jià)值。2.2 主從 Reactor 在 netpoll 中的體現(xiàn)傳統(tǒng) Reactor 模型分為 main reactor 和 sub reactor。main reactor 專門負(fù)責(zé) accept 新連接然后把新連接 fd 分發(fā)到某一個(gè) sub reactor 上sub reactor 則負(fù)責(zé)這個(gè)連接后續(xù)的可讀可寫事件。在 netpoll 里這個(gè)思想體現(xiàn)在兩個(gè)層面。第一它一般會(huì)起多個(gè) event loop默認(rèn)runtime.NumCPU()個(gè)新連接會(huì)通過(guò)一定的策略輪詢或者取最小負(fù)載分配給其中一個(gè) loop。第二每個(gè) loop 內(nèi)部是一個(gè)獨(dú)立的epoll_wait循環(huán)它只負(fù)責(zé)屬于這一路 loop 的連接事件。這樣多核 CPU 可以并行處理不同連接的事件不會(huì)因?yàn)橐话汛箧i導(dǎo)致全局阻塞。我當(dāng)時(shí)看到 netpoll 的EventLoop.Serve方法時(shí)第一反應(yīng)是它很像 Netty 的bossGroup和workerGroup的合體版。netpoll 里通常一個(gè) EventLoop 就同時(shí)承擔(dān)了 accept 和讀寫的責(zé)任但它用多個(gè) EventLoop 實(shí)例運(yùn)行來(lái)實(shí)現(xiàn)并行度。如果你對(duì) Netty 比較熟可以把 netpoll 理解成“多 worker 共享 accept 職責(zé)”的變形不夠純粹但是勝在簡(jiǎn)單高效。2.3 為什么在 Go 里還需要自研網(wǎng)絡(luò)庫(kù)可能有讀者會(huì)問(wèn)Go 標(biāo)準(zhǔn)庫(kù)不是已經(jīng)把 epoll 封裝好了嗎為什么還要自研因?yàn)闃?biāo)準(zhǔn)庫(kù)封裝的是一個(gè)通用 I/O 模型它面向的是“阻塞式 API runtime 調(diào)度”。這意味著每個(gè)conn.Read()調(diào)用都會(huì)把這個(gè) goroutine park 住直到數(shù)據(jù)可達(dá)。這是個(gè)傻瓜式的好用 API但代價(jià)是控制權(quán)不在你手里。你沒(méi)有辦法讓 event loop 在一次epoll_wait返回之后只挑出一批“真正該讀”的 fd 來(lái)讀跳過(guò)那些暫時(shí)沒(méi)數(shù)據(jù)的。在 netpoll 這類模型里網(wǎng)絡(luò)處理是顯式狀態(tài)機(jī)。你注冊(cè)了讀事件之后框架在做epoll_wait時(shí)會(huì)把可讀 fd 統(tǒng)統(tǒng)帶回來(lái)你在回調(diào)里明確知道這個(gè) fd 有數(shù)據(jù)于是非阻塞Read。整個(gè)過(guò)程不會(huì)出現(xiàn)“某個(gè) goroutine 掛在 Read 上沉睡”的情況而是“事件來(lái)了我再安排處理”。這個(gè)差異用一句話概括就是標(biāo)準(zhǔn)庫(kù)是一個(gè)連接一個(gè)協(xié)程地“人等數(shù)據(jù)”netpoll 是事件循環(huán)一把梭地“數(shù)據(jù)找人”。另外netpoll 自己還可以掌控內(nèi)存分配、事件批量處理、寫緩沖合并等細(xì)節(jié)。它甚至可以把多個(gè)連接的讀寫操作在同一個(gè)循環(huán)里分批執(zhí)行減少了系統(tǒng)調(diào)用次數(shù)和鎖競(jìng)爭(zhēng)。這些都是標(biāo)準(zhǔn)庫(kù)很難做到的數(shù)據(jù)面自由度。3. 從系統(tǒng)調(diào)用到事件循環(huán)的完整鏈路3.1 epoll 的三板斧create、ctl、wait在 Linux 上epoll 的使用套路非常固定。首先epoll_create1創(chuàng)建 epoll 實(shí)例然后epoll_ctl把一個(gè) fd 和關(guān)注的事件類型EPOLLIN、EPOLLOUT、EPOLLET 等綁定到實(shí)例上之后反復(fù)調(diào)用epoll_wait獲取已經(jīng)就緒的事件列表。netpoll 的 Poller 層會(huì)把這三步全部封裝成方法Open()負(fù)責(zé)創(chuàng)建 epoll fdControl()負(fù)責(zé)添加/修改/刪除注冊(cè)事件Wait()負(fù)責(zé)阻賽等待并返回事件數(shù)組。它返回的事件數(shù)組不是簡(jiǎn)單地給用戶一個(gè)整數(shù)掩碼而是打包好一個(gè)event結(jié)構(gòu)里面包含 fd、事件類型方便上層 HashMap 直接找到對(duì)應(yīng)的連接。這里有一個(gè)值得注意的細(xì)節(jié)netpoll 在網(wǎng)絡(luò)事件處理上做了“事件驅(qū)動(dòng)”和“非阻塞”的結(jié)合。注冊(cè)的 fd 默認(rèn)都是非阻塞模式這樣在epoll_wait返回說(shuō)“可讀”之后你調(diào)用read即使沒(méi)能一次讀完也不會(huì)把 goroutine 卡死而是借用內(nèi)部緩沖繼續(xù)循環(huán)讀直到返回EAGAIN再停手。3.2 EventLoop 的輪詢循環(huán)內(nèi)部長(zhǎng)什么樣看 netpoll 的核心循環(huán)大致可以拆成這幾步// 這是我對(duì) netpoll 主循環(huán)的示意細(xì)節(jié)以源碼為準(zhǔn) for { events : poller.Wait() for _, ev : range events { conn : connectionMap[ev.Fd] if ev.Readable { conn.HandleRead() } if ev.Writable { conn.HandleWrite() } if ev.Error { conn.Close() } } }這段邏輯看著樸素的像偽代碼但它其實(shí)是整個(gè)模型的心臟。poller.Wait()會(huì)阻塞直到內(nèi)核告訴它有事件拿到事件列表之后直接根據(jù) fd 找到連接對(duì)象按事件類型分發(fā)處理。事件處理是同步的好處是天然線程安全不需要為每個(gè)連接加鎖壞處是單個(gè)回調(diào)太慢會(huì)拖累整個(gè)事件循環(huán)。所以 netpoll 對(duì)用戶的OnRequest回調(diào)有明確建議不要在里面做重計(jì)算、不要調(diào)用阻塞 I/O。如果你確實(shí)有耗時(shí)的業(yè)務(wù)邏輯應(yīng)該在回調(diào)里把數(shù)據(jù) copy 出來(lái)丟到別的 goroutine 里去處理。這個(gè)約束是所有事件驅(qū)動(dòng)模型必須遵守的netty 有pipeline的線程模型netpoll 也有類似的邊界。3.3 事件緩沖區(qū)的巧妙之處每次epoll_wait都可能返回成百上千個(gè)就緒事件。如果每次等待都去make一個(gè)數(shù)組在高頻事件下 GC 壓力會(huì)很大。netpoll 的 Poller 在初始化時(shí)就會(huì)準(zhǔn)備一塊足夠大的事件緩沖數(shù)組并且每次Wait之后會(huì)復(fù)用這塊內(nèi)存只更新len。這樣既避免了頻繁分配又減少了 GC。這塊緩沖設(shè)計(jì)我在代碼里看到時(shí)是有點(diǎn)驚訝的它顯然從 Netty 那里學(xué)了不少。Netty 里叫epollEventArraynetpoll 里也是類似思路——一個(gè)[]epoll.Event的容器容量默認(rèn)可能開到MaxEventsPerLoop在線程/goroutine 內(nèi)部循環(huán)利用。這也提醒我們寫高性能網(wǎng)絡(luò)庫(kù)時(shí)“對(duì)象復(fù)用”和“池化”是繞不開的話題。另外epoll_wait的 timeout 參數(shù)在 netpoll 里也不是隨便設(shè)的。如果設(shè)置 too large可能會(huì)拖慢連接關(guān)閉、退出事件循環(huán)的響應(yīng)速度如果設(shè) too smallCPU 空轉(zhuǎn)又明顯。我看到 netpoll 在等待時(shí)采用了可變的 timeout 策略大致是“長(zhǎng)時(shí)間沒(méi)有事件時(shí)用較大 timeout事件密集時(shí)退避到較小 timeout”類似 Nginx 的 ngx_event 里對(duì) timer 的處理。這么做既保證低延遲又不會(huì)白白空轉(zhuǎn)燒 CPU。4. 連接狀態(tài)的流轉(zhuǎn)與讀寫緩沖設(shè)計(jì)4.1 連接狀態(tài)機(jī)從 Init 到 Closed學(xué)過(guò) TCP 狀態(tài)機(jī)的人應(yīng)該很熟悉網(wǎng)絡(luò)庫(kù)里“連接要有狀態(tài)”的思路。netpoll 里的連接對(duì)象也維護(hù)了一個(gè)狀態(tài)機(jī)主要狀態(tài)大致是Init連接對(duì)象剛創(chuàng)建還沒(méi)開始注冊(cè)事件Connectedfd 已注冊(cè)到 poller可以正常讀寫Closing/Closed表示連接正在關(guān)閉或已經(jīng)關(guān)閉。狀態(tài)機(jī)的價(jià)值在于約束操作。比如Write()如果發(fā)生在Closed狀態(tài)就不能再去碰 fd 了比如讀事件回調(diào)發(fā)現(xiàn)連接已經(jīng)被業(yè)務(wù)方 close 了就不能再去調(diào)用 HandleRead。實(shí)際源碼里經(jīng)常能看到atomic.StoreInt32(c.state, ...)這種操作因?yàn)檫B接對(duì)象可能被多個(gè) loop 或者多個(gè) goroutine 同時(shí)訪問(wèn)只有使用原子操作才能保證狀態(tài)可見性。我做連接池的時(shí)候吃過(guò)這個(gè)虧沒(méi)有狀態(tài)機(jī)直接判斷conn ! nil就復(fù)用結(jié)果在極端關(guān)閉時(shí)間點(diǎn)出現(xiàn)“fd 已經(jīng)被 epoll 移除但對(duì)象還被復(fù)用”的競(jìng)態(tài)線上出現(xiàn)莫名其妙的errno 9: Bad file descriptor。后來(lái)看了 netpoll 對(duì)連接的封裝發(fā)現(xiàn)它對(duì)狀態(tài)控制的粒度很細(xì)比如寫操作會(huì)先檢查isActive再檢查緩沖區(qū)是否有舊數(shù)據(jù)最后才決定要不要注冊(cè)寫事件。這個(gè)順序很重要反過(guò)來(lái)很容易出現(xiàn)“注冊(cè)了寫事件但緩沖區(qū)是空的”這種空轉(zhuǎn)事件。4.2 讀流程非阻塞讀到 EAGAIN 為止讀事件觸發(fā)后netpoll 會(huì)嘗試把 fd 里的數(shù)據(jù)盡量讀出來(lái)。它內(nèi)部維護(hù)了一個(gè)輸入緩沖區(qū)InputBuffer讀到的數(shù)據(jù)先append到緩沖區(qū)里然后觸發(fā)OnRequest之類的回調(diào)讓你消費(fèi)緩沖區(qū)里的數(shù)據(jù)。為什么非要“讀到 EAGAIN 為止”因?yàn)?epoll 是水平觸發(fā)的話如果你不讀完下次epoll_wait還會(huì)繼續(xù)上報(bào)可讀事件會(huì)造成重復(fù)通知。netpoll 默認(rèn)使用 LT 還是 ET 我不展開討論重要的是非阻塞讀加一個(gè)大一點(diǎn)的緩沖區(qū)可以避免反復(fù) wakeup提升吞吐。反過(guò)來(lái)如果一次只讀一點(diǎn)數(shù)據(jù)就交給業(yè)務(wù)每次事件只能消費(fèi)一點(diǎn)事件通知次數(shù)會(huì)成倍增加效率自然難看。讀緩沖區(qū)的增長(zhǎng)策略也需要關(guān)注。連接剛建立時(shí)通常會(huì)給一個(gè)較小的初始 buffer比如 2KB 或 4KB之后按需擴(kuò)容。netpoll 里 buffer 部分直接引用了runtime的growslice思想擴(kuò)容時(shí)按倍數(shù)擴(kuò)大避免頻繁 copy。我在用標(biāo)準(zhǔn)庫(kù)bufio.Reader時(shí)也愛用大一點(diǎn)的初始化 size本質(zhì)原因都一樣。4.3 寫流程寫緩沖合并與事件注冊(cè)寫路徑比讀路徑更繞。業(yè)務(wù)方調(diào)用Write()時(shí)數(shù)據(jù)其實(shí)不是直接進(jìn)內(nèi)核發(fā)送而是先寫到連接的輸出緩沖區(qū)OutputBuffer。之后 netpoll 會(huì)根據(jù) fd 的當(dāng)前狀態(tài)決定如果 fd 當(dāng)前可寫就直接嘗試 flush 緩沖區(qū)如果上一次還有沒(méi)發(fā)完的數(shù)據(jù)就在 poller 上注冊(cè) EPOLLOUT 事件等著內(nèi)核通知可寫再繼續(xù)發(fā)。這里有個(gè)細(xì)節(jié)EPOLLOUT事件不是一直注冊(cè)著的因?yàn)榇蟛糠謺r(shí)間連接都是可寫的注冊(cè)了反而會(huì)頻繁觸發(fā)“可寫”事件造成忙輪詢。netpoll 的做法是延遲到“確實(shí)有寫不出去的數(shù)據(jù)”時(shí)才注冊(cè)寫事件。這個(gè)設(shè)計(jì)我很認(rèn)同相當(dāng)于把最昂貴的epoll_ctl系統(tǒng)調(diào)用次數(shù)壓縮到了最少。另外寫緩沖合并也是 netpoll 降低系統(tǒng)調(diào)用量的手段。比如業(yè)務(wù)連續(xù)兩次Write()如果前后間隔極短netpoll 可以先合并在同一個(gè)用戶態(tài)緩沖區(qū)里再一次writev發(fā)出去。這活兒看起來(lái)簡(jiǎn)單實(shí)際上要處理“并發(fā)寫鎖”和“緩沖區(qū)游標(biāo)”的問(wèn)題做差了容易丟數(shù)據(jù)或者亂序。4.4 內(nèi)存復(fù)用與池化高并發(fā)網(wǎng)絡(luò)庫(kù)里內(nèi)存分配是性能大頭之一。每次都從堆上 make 一個(gè) bytes slice 用來(lái)裝網(wǎng)絡(luò)數(shù)據(jù)沒(méi)有池化GC 壓力會(huì)巨大。netpoll 在緩沖池這塊下了不少功夫?qū)ψx緩沖、寫緩沖都做了復(fù)用。簡(jiǎn)單說(shuō)就是連接關(guān)閉后它的輸出緩沖和讀緩沖對(duì)象可以放回池子里新連接創(chuàng)建時(shí)再掏出來(lái)用省掉了反復(fù)malloc的開銷。我看 pprof 數(shù)據(jù)時(shí)特別喜歡關(guān)注runtime.mallocgc的占比。用標(biāo)準(zhǔn)庫(kù)寫網(wǎng)絡(luò)服務(wù)malloc 占比經(jīng)常在 15%~25% 之間徘徊換到 netpoll 加連接池這個(gè)數(shù)字能壓到 10% 以下。這不僅僅是框架的功勞和業(yè)務(wù)側(cè)盡量復(fù)用 []byte 也有關(guān)系。框架能幫你做的只是減少“連接級(jí)緩沖”的分配業(yè)務(wù)回調(diào)里如果每次都append出新的 sliceGC 還是躲不掉。5. 高性能的關(guān)鍵批量、零拷貝與多路復(fù)用5.1 用 readv 聚合多個(gè)緩沖區(qū)readv是 Linux 提供的一個(gè)系統(tǒng)調(diào)用它允許一次 read 操作把數(shù)據(jù)寫到多個(gè)內(nèi)存塊中。netpoll 在讀事件里可以使用readv把數(shù)據(jù)分別讀到“read buffer 的剩余空間”和“額外準(zhǔn)備的輔助 buffer”中這樣即使 fd 上的數(shù)據(jù)比當(dāng)前緩沖剩余空間還多也能一次性拿到更多數(shù)據(jù)減少系統(tǒng)調(diào)用次數(shù)。這個(gè)操作對(duì)“一次事件處理盡量多收數(shù)”特別有效。普通read可能一次只能搬到大小為 4KB 的緩沖區(qū)然后發(fā)現(xiàn)還有數(shù)據(jù)又要再 read 一次readv則可以只調(diào)用一次內(nèi)核先把填充當(dāng)前 buffer再把剩下的數(shù)據(jù)填充到第二個(gè) buffer系統(tǒng)調(diào)用次數(shù)能省一半以上。netpoll 一般在 buffer 不足時(shí)會(huì)走這個(gè)邏輯但是具體觸發(fā)條件需要看代碼里對(duì)Grow策略的設(shè)計(jì)。我自己的實(shí)踐體會(huì)是大包場(chǎng)景下 readv 收益非常明顯小包場(chǎng)景下效果平平因?yàn)橄到y(tǒng)調(diào)用次數(shù)大頭主要在事件本身而不是 read 次數(shù)。5.2 writev 聚合小包發(fā)送對(duì)應(yīng)的寫側(cè)有writev一次調(diào)用可以把多個(gè)內(nèi)存塊的數(shù)據(jù)順序發(fā)送到內(nèi)核。netpoll 的寫緩沖結(jié)構(gòu)天然適合配合 writev輸出緩沖區(qū)可能殘留之前的半截?cái)?shù)據(jù)業(yè)務(wù)又追加了新的數(shù)據(jù)這兩段數(shù)據(jù)不連續(xù)但用 writev 可以一次發(fā)出。小包聚合對(duì) RPC 框架來(lái)說(shuō)尤其重要。微服務(wù)一次請(qǐng)求/響應(yīng)體量通常只有幾百字節(jié)到幾 KB如果每個(gè)包都立刻發(fā)送TCP 層面會(huì)釋放大量小包網(wǎng)絡(luò)棧消耗很高。netpoll 在寫路徑上通常會(huì)有“延遲 flush”或者“批量 flush”的取舍不過(guò)需要小心過(guò)度合并會(huì)增大消息延遲尤其對(duì)首包延遲敏感的服務(wù)不是好事。我在壓測(cè)時(shí)觀察過(guò)開啟小包合并且觸發(fā)條件設(shè)置合理時(shí)CPU 的 sys 占比能降低 3~5 個(gè)百分點(diǎn)。代價(jià)是單條消息的 p99 延遲可能從 0.5ms 漲到 1ms 左右。所以“要不要合并”要結(jié)合業(yè)務(wù) SLA 去權(quán)衡不是一味追求聚合就好。5.3 零拷貝與 sendfile 的適用邊界很多文章一提到高性能網(wǎng)絡(luò)庫(kù)就要聊零拷貝。netpoll 里對(duì) sendfile 這類機(jī)制有所涉及主要場(chǎng)景是服務(wù)端向客戶端發(fā)送文件數(shù)據(jù)比如靜態(tài)資源服務(wù)。通過(guò)sendfile系統(tǒng)調(diào)用可以直接把文件內(nèi)容從內(nèi)核頁(yè)緩存發(fā)送到 socket不需要把數(shù)據(jù)從內(nèi)核拷貝到用戶態(tài)也不需要用戶態(tài)再拷到 socket buffer。但注意RPC 場(chǎng)景下絕大多數(shù)消息是業(yè)務(wù)生成的響應(yīng)體不在文件里所以 sendfile 的適用場(chǎng)景沒(méi)想象中那么大。真正在 RPC 數(shù)據(jù)路徑上發(fā)力的還是“減少用戶態(tài)和內(nèi)核態(tài)之間無(wú)意義的拷貝次數(shù)”也就是盡量復(fù)用緩沖、避免業(yè)務(wù)層 copy。netpoll 的緩沖設(shè)計(jì)讓 OnRequest 回調(diào)拿到的 []byte 可以在業(yè)務(wù)處理完之后直接把同一個(gè)底層數(shù)組用于響應(yīng)不需要多余的拷貝這種情況下比標(biāo)準(zhǔn)庫(kù)的多次 copy 要省。關(guān)于splice它也是零拷貝的一種方式但復(fù)雜度更高我見過(guò)不少團(tuán)隊(duì)在 TCP 代理場(chǎng)景里想用 splice最后因?yàn)檫吔鐥l件處理太復(fù)雜放棄了。netpoll 官方也沒(méi)有把它作為核心特性更多還是依賴 readv/writev 加緩沖池來(lái)達(dá)到性能目標(biāo)。5.4 減少 epoll_ctl 的調(diào)用次數(shù)epoll_ctl 是系統(tǒng)調(diào)用不能隨便打尤其是高并發(fā)下早于事件通知而反復(fù)修改監(jiān)聽事件會(huì)帶來(lái)巨大的用戶態(tài)與內(nèi)核態(tài)切換開銷。netpoll 在這方面做了很多優(yōu)化比如寫事件延遲注冊(cè)、讀事件盡量常駐監(jiān)聽、通過(guò) update 事件掩碼來(lái)避免刪除再添加。有一點(diǎn)讓我印象很深它把“fd 是否需要注冊(cè)寫事件”的判斷放到了寫路徑的末尾而不是每次 Write 都調(diào) epoll_ctl。這樣做的目的在于把 epoll_ctl 的調(diào)用頻次從“每次業(yè)務(wù)寫”降低到“每次遇到寫阻塞”。系統(tǒng)調(diào)用頻次的優(yōu)化在高 QPS 服務(wù)下關(guān)系重大每次 syscall 即便只有 1~2 微秒峰值時(shí)也會(huì)迅速疊加成可觀的 CPU 消耗。6. 用 netpoll 寫一個(gè)最小服務(wù)以及源碼閱讀路線6.1 五步搭一個(gè) echo server單純看模型容易飄上手跑一個(gè)例子理解最快。netpoll 的應(yīng)用層 API 非常簡(jiǎn)潔一個(gè)最小 echo server 大概是這樣的package main import ( context fmt github.com/cloudwego/netpoll ) func main() { eventLoop, err : netpoll.NewEventLoop(func(ctx context.Context, connection netpoll.Connection) error { // 讀取連接上當(dāng)前可讀的所有數(shù)據(jù) reader : connection.Reader() data : make([]byte, reader.Len()) _, _ reader.Read(data) // 原樣寫回去 writer : connection.Writer() _ writer.WriteBinary(data) return writer.Flush() }) if err ! nil { panic(err) } err eventLoop.Serve(netpoll.NewListener(tcp, :8080)) if err ! nil { fmt.Println(serve error:, err) } }這段代碼的處理邏輯是這樣的注冊(cè)一個(gè)OnRequest回調(diào)連接有數(shù)據(jù)可讀時(shí)框架會(huì)Read出來(lái)拼接到reader里然后你從reader里把數(shù)據(jù)拿出來(lái)再通過(guò)writer寫回。Flush()是真正觸發(fā)底層寫路徑的入口它會(huì)把輸出緩沖區(qū)交給連接去 flush。從這個(gè)小例子能看到兩層結(jié)構(gòu)事件循環(huán)層EventLoop.Serve負(fù)責(zé)接收連接和分發(fā)事件連接層Connection負(fù)責(zé)提供 Reader/Writer 這樣的流式讀寫接口。實(shí)際項(xiàng)目中我建議把 OnRequest 中間的 copy 去掉而是直接復(fù)用 netpoll 的連接緩沖來(lái)構(gòu)造響應(yīng)。因?yàn)樵?baseline 上每個(gè)請(qǐng)求都make([]byte, reader.Len())的話GC 很快會(huì)把你辛苦省下來(lái)的性能又還回去。6.2 常用配置項(xiàng)說(shuō)明netpoll 的配置項(xiàng)不算多但每一個(gè)都值得調(diào)優(yōu)時(shí)有意識(shí)地去改。我用的比較頻繁的幾個(gè)WithNumLoops指定 event loop 數(shù)量一般等于 CPU 核數(shù)。WithReadTimeout連接讀超時(shí)超時(shí)連接會(huì)被框架關(guān)閉。WithWriteTimeout寫超時(shí)對(duì)異常連接的兜底非常重要。WithIdleTimeout空閑連接超時(shí)常用于服務(wù)端主動(dòng)淘汰不再活躍的連接。在這些參數(shù)里我最關(guān)注WithIdleTimeout。很多長(zhǎng)連接服務(wù)會(huì)把空閑連接一直放著不管時(shí)間一長(zhǎng)服務(wù)端 fd 數(shù)量不斷攀升最終觸發(fā)too many open files。netpoll 提供了這個(gè)參數(shù)可以方便地清理閑置連接但設(shè)得太短會(huì)把一些低頻但正常的連接誤殺所以經(jīng)驗(yàn)值是結(jié)合業(yè)務(wù)?；顧C(jī)制比如心跳間隔去設(shè)置一般設(shè)為心跳間隔的 2~3 倍。6.3 源碼閱讀建議如果你想深入源碼我建議不要從最外層EventLoop開始讀那樣容易被大量封裝干擾。我的閱讀路徑是先看netpoll/polling包了解 epoll/kqueue 的封裝這是整個(gè)模型的地基再看netpoll/connection包重點(diǎn)看Connection的讀寫緩沖、事件注冊(cè)、狀態(tài)流轉(zhuǎn)最后回到netpoll/eventloop包看它怎么把連接注冊(cè)到 poller、如何在 loop 循環(huán)里分發(fā)事件。閱讀時(shí)盯住三個(gè)核心行為HandleRead、HandleWrite、Close。把這三個(gè)方法看懂了整個(gè) netpoll 的網(wǎng)絡(luò)生命周期就通了。那些關(guān)于 buffer 的零碎代碼可以在有性能調(diào)優(yōu)需求時(shí)再回頭細(xì)看。另外閱讀時(shí)最好用 Linux 環(huán)境因?yàn)?kqueue 分支和 epoll 分支多少有點(diǎn)差異Linux 是最常用的生產(chǎn)環(huán)境理解 epoll 路徑收益最大。7. 線上踩坑與排查經(jīng)驗(yàn)實(shí)錄7.1 回調(diào)里做耗時(shí)操作整個(gè) loop 都被拖垮事件驅(qū)動(dòng)模型最大的坑就是這個(gè)。某個(gè)連接的 OnRequest 里如果做了一次較慢的 DB 查詢比如 50ms那同一 EventLoop 上其他所有連接的事件都會(huì)排在這 50ms 之后。結(jié)果就是“一個(gè)連接慢拖垮一批連接”現(xiàn)象經(jīng)常是部分請(qǐng)求的延遲突然拉高。排查方法很直接在 OnRequest 入口和出口打點(diǎn)看單次回調(diào)耗時(shí)的 p99。如果發(fā)現(xiàn)回調(diào)本身耗時(shí)過(guò)高就要把業(yè)務(wù)邏輯拆出去用 goroutine 并發(fā)處理。數(shù)據(jù)要特別注意netpoll 的 Reader 是連接緩沖跨 goroutine 使用前必須先 copy 出來(lái)否則緩沖被后續(xù)事件復(fù)用后數(shù)據(jù)就亂了。提示OnRequest 回調(diào)應(yīng)該是“純網(wǎng)絡(luò)數(shù)據(jù)處理邏輯”任何 I/O 等待、鎖等待、重量級(jí)計(jì)算都應(yīng)該放到回調(diào)外的 goroutine 里去做。7.2 連接泄漏與 fd 耗盡用 netpoll 后連接數(shù)不等于 goroutine 數(shù)所以連接泄漏更隱蔽。fd 耗盡時(shí)服務(wù)表現(xiàn)是新建連接失敗Accept報(bào)EMFILE但存量請(qǐng)求看起來(lái)還正常。這時(shí)候一般是被某個(gè)業(yè)務(wù)邏輯忘記 Close 連接了。我遇到過(guò)一次比較隱蔽的情況客戶端的連接異常斷開后服務(wù)端沒(méi)有及時(shí)感知因?yàn)閼?yīng)用層沒(méi)有設(shè)置讀寫超時(shí)。內(nèi)核可能在很長(zhǎng)時(shí)間后才發(fā)出 FIN/RST期間這條半開連接一直占著 fd。解決辦法有兩步一是設(shè)置合理的ReadTimeout或IdleTimeout二是在 OnRequest 里針對(duì)協(xié)議心跳做校驗(yàn)連續(xù) N 次心跳超時(shí)主動(dòng)關(guān)閉連接。排查 fd 泄漏可以用lsof -p pid | wc -l快速看數(shù)量如果持續(xù)增長(zhǎng)再通過(guò)strace -p pid -f -e traceaccept4,close看系統(tǒng)調(diào)用的 accept 和 close 頻率基本能定位到漏掉的 Close。7.3 Nagle 算法與 TCP_NODELAY 的微妙關(guān)系Go 標(biāo)準(zhǔn)庫(kù)默認(rèn)會(huì)把 TCP_NODELAY 打開也就是禁用 Nagle 算法保證小包不延遲。netpoll 繼承了這一點(diǎn)默認(rèn)連接都是 NODELAY。但有次我遇到一個(gè)問(wèn)題服務(wù)某條鏈路的延遲偶發(fā)跳到幾十毫秒排查很久發(fā)現(xiàn)是我們自己的網(wǎng)關(guān)層在“收到響應(yīng)后不立刻 flush而是等下一波事件時(shí)再 flush”和 Nagle 無(wú)關(guān)屬于業(yè)務(wù)緩沖策略過(guò)度。這類問(wèn)題提醒我寫完業(yè)務(wù)代碼后要關(guān)注 writer.Flush 的觸發(fā)時(shí)機(jī)。如果你在回調(diào)里只 Write 不 Flush數(shù)據(jù)會(huì)一直積壓在用戶態(tài)緩沖里看起來(lái)像網(wǎng)絡(luò)延遲實(shí)際是框架還沒(méi)把數(shù)據(jù)發(fā)給內(nèi)核。正確做法是確定當(dāng)前處理邏輯完成后立刻 Flush除非你有明確的批量化意圖。7.4 低并發(fā)小場(chǎng)景下netpoll 可能反而不值得netpoll 不是銀彈。如果你的服務(wù)連接數(shù)只有幾百請(qǐng)求頻率不高標(biāo)準(zhǔn)庫(kù)的 goroutine-per-conn 模型寫起來(lái)簡(jiǎn)單維護(hù)性也更好性能差異在低并發(fā)下微乎其微。強(qiáng)行上 netpoll反而要處理回調(diào)限制、緩沖生命周期、事件循環(huán)阻塞這些復(fù)雜問(wèn)題。我見過(guò)一個(gè)團(tuán)隊(duì)在內(nèi)部管理系統(tǒng)的上報(bào)接口里強(qiáng)行引入 netpoll最后寫出來(lái)的代碼比標(biāo)準(zhǔn)庫(kù)復(fù)雜得多性能收益卻幾乎沒(méi)有。高性能方案是有成本的只有連接規(guī)模大到標(biāo)準(zhǔn)庫(kù)模型開始難受時(shí)netpoll 才真正體現(xiàn)價(jià)值。這也算是我這幾年做技術(shù)選型的一個(gè)原則先用量化指標(biāo)確認(rèn)瓶頸再?zèng)Q定是否引入更復(fù)雜的模型。7.5 注意與 Go runtime 調(diào)度器的邊界Go 本身有 goroutine 和 runtime schedulernetpoll 的事件循環(huán)也是跑在 goroutine 上的。這帶來(lái)一個(gè)問(wèn)題事件循環(huán) goroutine 如果頻繁被 Go runtime 調(diào)度走比如其他 goroutine 大量占 CPU網(wǎng)絡(luò)事件處理的實(shí)時(shí)性會(huì)受影響。雖然 Go 的調(diào)度器在 GMP 模型下已經(jīng)盡量降低這種影響但極端情況下比如某個(gè) goroutine 進(jìn)入runtime.LockOSThread長(zhǎng)時(shí)間持有線程事件循環(huán)的調(diào)度還是會(huì)出現(xiàn)卡頓。所以在部署 netpoll 服務(wù)時(shí)我會(huì)盡量保持 CPU 負(fù)載在 70% 以下避免調(diào)度器為了搶 CPU 產(chǎn)生顯著抖動(dòng)。同時(shí)把GOMAXPROCS設(shè)置成容器/機(jī)器的物理核數(shù)不要盲目調(diào)大否則事件循環(huán) goroutine 多了反而增加調(diào)度開銷。最后分享一點(diǎn)我的實(shí)際體會(huì)這個(gè)模型我在生產(chǎn)環(huán)境跑了快兩年從一開始把 netpoll 當(dāng)性能銀彈到后來(lái)慢慢理解它是為某個(gè)特定場(chǎng)景大規(guī)模長(zhǎng)連接、低延遲 RPC而生的中間走了不少?gòu)澛贰，F(xiàn)在我做技術(shù)方案時(shí)會(huì)先想清楚三個(gè)問(wèn)題連接數(shù)大概多少消息大小分布如何延遲要求多嚴(yán)格這三個(gè)問(wèn)題答案不同選型就完全不一樣。netpoll 讓我最佩服的地方不是某個(gè)單一系統(tǒng)調(diào)用而是它對(duì)整個(gè)網(wǎng)絡(luò)數(shù)據(jù)路徑的精細(xì)化控制事件循環(huán)、緩沖池、系統(tǒng)調(diào)用聚合、狀態(tài)機(jī)。這些點(diǎn)單獨(dú)看都不算難但組合在一起就成了一個(gè)能打高并發(fā)的工業(yè)級(jí)網(wǎng)絡(luò)庫(kù)。如果你也在做 Go 網(wǎng)絡(luò)服務(wù)我建議先跑一跑它官方的 benchmark再對(duì)照 pprof 看自己的瓶頸點(diǎn)到底在哪里然后決定要不要把模型切過(guò)去。這比聽我說(shuō)一百句“它很高效”都要有用。