寫服務端程序這些年最大的一個感悟就是連接多了以后真正卡住你的往往不是CPU也不是內(nèi)存而是事件怎么被組織起來。很多人一上來就寫while(1) { accept(); handle(); }幾千連接時勉強能跑幾萬連接時直接崩問題就出在模型上。這篇就聊聊Linux下非常經(jīng)典的一套組合拳Epoll-Reactor模式它把epoll這個事件通知機制和Reactor這個事件分發(fā)架構(gòu)揉在一起解決高并發(fā)網(wǎng)絡服務的核心問題。讀完你不僅能理解為什么主流的網(wǎng)絡框架都長這樣還能自己動手搭出一個能處理上萬連接的骨架后面要加協(xié)議解析、加業(yè)務邏輯都是在這個結(jié)構(gòu)上做文章。1. Epoll-Reactor模式要解決的核心問題1.1 傳統(tǒng)模型為什么扛不住高并發(fā)先回到最原始的阻塞IO時代。最早的網(wǎng)絡服務寫法很直白主線程accept()一個連接然后創(chuàng)建一個線程去處理這個連接的讀寫。這個模型在小并發(fā)下確實好用邏輯直觀、排查方便但連接數(shù)一旦上來幾個問題就特別突出。第一個問題是線程數(shù)量失控。每個連接一個線程1萬個連接就是1萬個線程每個線程默認?？臻g就有8MB光棧內(nèi)存就把虛擬地址空間吃沒了更不要說線程切換的上下文開銷。第二個問題是阻塞調(diào)用浪費資源。線程在recv()上等數(shù)據(jù)時CPU完全是空閑的這本身倒也不致命但大量空閑線程擠在一起調(diào)度器會很累。第三個問題是accept()本身就很容易變成瓶頸。后來大家改用select和poll。這類IO多路復用模型的好處是一個進程可以同時監(jiān)視很多個socket你在收到事件通知后就知道哪些fd可讀可寫不再需要為每個連接配一個線程。但這倆老家伙也有硬傷select的連接數(shù)被FD_SETSIZE限制在1024你要調(diào)大還得重新編譯內(nèi)核每次調(diào)用都要把整個fd集合從用戶態(tài)拷到內(nèi)核態(tài)再拷回來O(n)的遍歷開銷在1萬連接以上特別明顯。epoll的出現(xiàn)把這些煩心事一次性解決了。它的核心是三個接口epoll_create1()創(chuàng)建實例epoll_ctl()增刪改監(jiān)視的fdepoll_wait()等待就緒事件。內(nèi)核里維護一棵紅黑樹和一個就緒鏈表你每次只需要處理真正有事件的fd復雜度從O(n)降到O(1)而且沒有fd數(shù)量上限。這玩意兒一出來C10K問題在代碼層面才算是真正有了可行的解法。但這里有個很容易被忽略的點epoll只解決事件通知這件事它告訴你第1000號fd可讀了可它不告訴你接下來該怎么辦。誰來accept()新連接誰來讀取數(shù)據(jù)讀到數(shù)據(jù)之后誰來解析、誰來處理業(yè)務、誰來回包這些活兒如果全部堆在epoll_wait返回后的一個循環(huán)里代碼很快就會亂成一鍋粥而且一旦某個fd的處理邏輯卡住整個進程的監(jiān)視循環(huán)就癱了。1.2 引入Reactor模式讓事件有自己的崗位分工Reactor模式解決的就是事件來了以后怎么辦的問題。它的核心思想很簡單把事件的檢測和事件的處理徹底拆開由統(tǒng)一的中心器負責監(jiān)聽和分發(fā)各個業(yè)務模塊只負責處理分配到自己頭上的事件。用個生活化的類比。你開了一家餐廳門口有個迎賓員他的職責只有一個看到有客人來了把他們領到對應的餐臺通知對應的服務員去接待。迎賓員自己不炒菜不端盤子不結(jié)賬。炒菜是后廚的事端菜是服務員的事結(jié)賬是收銀臺的事。這個迎賓員就是Reactorepoll就是他那雙眼睛而每一個具體的連接就是一位等著被服務的客人。對應到代碼世界經(jīng)典的Reactor模式里有這么幾個角色事件源即連接套接字fd它是一切的起點。事件多路分發(fā)器epoll組件負責向Reactor登記事件、等待事件出現(xiàn)。Reactor核心可以理解為一個事件循環(huán)它調(diào)用epoll_wait()拿到就緒事件然后根據(jù)事件的類型調(diào)用對應的事件處理器。Acceptor專門處理有新連接到來這一類事件做accept()操作把新的fd登記進epoll。事件處理器負責業(yè)務邏輯比如讀數(shù)據(jù)、解碼、處理、編碼、寫回細分還能拆出讀Handler和寫Handler。這套結(jié)構(gòu)的好處是每個模塊只干一件事。epoll只做事件通知Reactor只做分發(fā)業(yè)務邏輯全部封裝在Handler里。你想換協(xié)議只要改Handler不用動事件循環(huán)你想調(diào)并發(fā)模型把單線程Reactor換成多線程ReactorAcceptor和Handler的代碼基本不用動。這種低耦合在你項目迭代到中后期時才真正體會到有多爽?？赡苡腥藭栔苯釉谝粋€死循環(huán)里拿到事件、然后switch(event.type)去處理不行嗎行小項目完全行。但你看accept()要處理讀數(shù)據(jù)要處理寫數(shù)據(jù)要處理超時連接要處理異常斷開要處理每個分支越來越長任何一個人加邏輯都可能碰壞另一條線。Reactor模式的意義就是把這些開關的角色預先定死讓架構(gòu)穩(wěn)定住。2. Epoll細節(jié)不能含糊觸發(fā)模式、事件封裝與線程模型2.1 水平觸發(fā)LT和邊沿觸發(fā)ET兩種模式的實戰(zhàn)差異用epoll時有兩種觸發(fā)模式很多人卡在ET上其實理解透了特別簡單。水平觸發(fā)Level-TriggeredLT是默認模式。它就像你手機上的消息通知只要你有未讀消息它就一直提醒你不管你看沒看。對應到socket上只要緩沖區(qū)里還有數(shù)據(jù)沒讀完epoll_wait()每次都會把這個fd返回給你就算你只讀取了1個字節(jié)剩下的數(shù)據(jù)還會在下一次等待中再次觸發(fā)。這種模式實現(xiàn)簡單不容易漏數(shù)據(jù)但缺點是如果數(shù)據(jù)量大而你每次又讀得少同一個fd會被反復喚醒浪費一點CPU。邊沿觸發(fā)Edge-TriggeredET則是只在狀態(tài)變化時通知一次。就像門鈴你按一下它響一聲門開了再關上它不會因為你一直站在門口就反復響。對應到socket上只有新數(shù)據(jù)到達時它才觸發(fā)一次之后就算緩沖區(qū)里還有些許數(shù)據(jù)沒讀完epoll也不會再提醒你除非又有新數(shù)據(jù)到達。這種模式效率高每一次喚醒都是有增量但代價是你必須一次把緩沖區(qū)里的數(shù)據(jù)全部讀干凈否則就會把沒處理完的數(shù)據(jù)悶在緩沖區(qū)里客戶端等著響應服務端傻等通知形成死鎖一樣的狀態(tài)。實際編碼中兩種模式對代碼結(jié)構(gòu)的影響不小我整理了一下區(qū)別對比項水平觸發(fā)LT邊沿觸發(fā)ET默認狀態(tài)epoll默認模式需要通過EPOLLET顯式開啟未處理數(shù)據(jù)是否重復通知會反復提醒直到讀完不會只在狀態(tài)變化時提醒一次讀取要求讀到recv返回0為止即可允許分次必須循環(huán)讀到EAGAIN否則數(shù)據(jù)殘留編寫難度低適合入門和邏輯簡單場景高對狀態(tài)管理要求更嚴格觸發(fā)頻率高存在無效喚醒低理論效率更高適用場景業(yè)務簡單、需要穩(wěn)妥的做法高吞吐、機器資源吃緊的網(wǎng)絡服務這里有個非常普遍的認知誤區(qū)有人說ET一定比LT快所以無腦上ET。實際上在高版本內(nèi)核里LT和ET的損耗差距極小真正拉開差距的是事件被喚醒的頻次和每次處理數(shù)據(jù)的方式。如果你的業(yè)務是小包高頻通信LT反而省心如果你做的是大數(shù)據(jù)量傳輸ET配合正確的讀取循環(huán)性能上限確實更高。個人建議剛開始實現(xiàn)Reactor骨架的時候先用LT把事件分發(fā)、連接管理這些邏輯跑通后面再切換到ET做專項優(yōu)化。一次把兩件事都做好出問題了很難排查。2.2 單線程Reactor、多線程Reactor、主從Reactor怎么選Reactor模式里另一個繞不開的問題Reactor循環(huán)本身跑在哪個線程里業(yè)務Handler又跑在哪個線程里先看最簡單的單線程Reactor。Reactor、Acceptor、所有連接的Handler全部擠在一個線程里。流程是epoll_wait()返回一批事件依次執(zhí)行對應處理。這個模型最大的優(yōu)點是代碼簡單沒有鎖也很少出現(xiàn)并發(fā)問題對一個連接的處理永遠是串行的。但缺點同樣致命任何一個Handler中的阻塞操作都會讓整個服務停止響應。比如某個Handler里做了數(shù)據(jù)庫查詢、磁盤IO、或者一個sleep()那這個線程的所有其他連接就全部排隊等著相當于整個服務按下了暫停鍵。所以單線程Reactor只適用于業(yè)務極輕、不涉及阻塞調(diào)用的場景比如簡單的網(wǎng)關轉(zhuǎn)發(fā)、協(xié)議探測服務。再進一步多線程Reactor。Reactor主循環(huán)還是獨占一個線程這線程只做事件分發(fā)和accept()新連接但Handler接到事件后不再直接處理業(yè)務而是把任務丟給工作線程池。線程池里的線程負責真正的讀數(shù)據(jù)、解碼、業(yè)務計算、編碼與寫操作。這種模型把監(jiān)聽的線程和干活的線程分開來事件循環(huán)永遠不會被業(yè)務阻塞。代價是一個連接上的讀和寫可能落在不同的工作線程上需要處理好同步問題而且多個線程同時處理不同連接時共享數(shù)據(jù)要考慮加鎖或用無鎖結(jié)構(gòu)。再往后還有主從Reactor多線程模型。它把Reactor本身也拆成兩種主Reactor只負責管理監(jiān)聽套接字、接受新連接子Reactor負責管理已連接套接字上的IO事件。也就是主Reactor拿著監(jiān)聽fdaccept()出來的新fd分配給某個子Reactor去管理每個子Reactor有自己獨立的epoll實例和線程。這種架構(gòu)在繁重連接場景下能更好地利用多核也是很多工業(yè)級網(wǎng)絡框架采用的方案一個主線程Hold住監(jiān)聽socket多個子線程各自跑一個Reactor循環(huán)業(yè)務線程池再兜底。選擇建議先從實際項目出發(fā)連接量大、業(yè)務簡單比如轉(zhuǎn)發(fā)、心跳維護選主從ReactorIO事件分散到多個線程里最劃算。連接量中等、業(yè)務復雜比如涉及本地數(shù)據(jù)庫選多線程Reactor把阻塞業(yè)務從主循環(huán)里摘出去。純學習、或者連接量就幾百單線程Reactor完全夠用先把這套框架理解透再說。3. 動手搭一個Epoll-Reactor服務端骨架3.1 整體結(jié)構(gòu)設計組件劃分和職責邊界寫代碼之前先把模塊結(jié)構(gòu)定清楚這是整個Reactor能跑起來的關鍵。我這個項目里分了五個核心組件每個都有明確的職責。EventLoop是最核心的類內(nèi)部封裝一個epoll實例并且提供注冊、修改、刪除fd事件的方法主循環(huán)loop()里調(diào)用epoll_wait()并循環(huán)處理就緒事件。Channel則是fd和事件回調(diào)的封裝一個Channel對應一個fd它知道自己關心什么事件也持有事件觸發(fā)時該調(diào)用的回調(diào)函數(shù)指針。Acceptor專門負責監(jiān)聽套接字持有監(jiān)聽fd對應的Channel一旦監(jiān)聽到可讀事件就執(zhí)行accept()并創(chuàng)建新的連接對象。TcpConnection代表一個已建立的連接內(nèi)部有讀緩沖、寫緩沖以及對應fd的Channel它處理的是這個連接上的可讀可寫事件。ThreadPool是業(yè)務線程池EventLoop收到事件后把耗時操作交給它去跑。組件之間的協(xié)作流程用文字描述是這樣一條線進程啟動時先創(chuàng)建EventLoop再創(chuàng)建Acceptor并注冊監(jiān)聽fdEventLoop進入循環(huán)后epoll_wait()阻塞等待一旦監(jiān)聽fd可讀Acceptor的Channel回調(diào)被觸發(fā)執(zhí)行accept()新fd封裝成TcpConnection把它注冊到這個EventLoop上當這個新fd可讀時TcpConnection的Channel回調(diào)觸發(fā)讀取數(shù)據(jù)、做初步解析把耗時的業(yè)務邏輯派發(fā)到ThreadPoolThreadPool處理完后把回包數(shù)據(jù)放進TcpConnection的寫緩沖觸發(fā)可寫事件由EventLoop統(tǒng)一寫出。這個流程走的其實是典型的事件驅(qū)動鏈路事件從內(nèi)核產(chǎn)生經(jīng)過epoll、EventLoop、Channel一路派發(fā)到業(yè)務代碼。整個鏈路里沒有任何一個CPU在空轉(zhuǎn)等待只要沒人阻塞事件循環(huán)吞吐就能持續(xù)跑起來。3.2 核心實現(xiàn)EventLoop封裝與事件循環(huán)先看EventLoop里最容易出錯的封裝。很多新手會把epoll_create、epoll_ctl、epoll_wait散落在各處調(diào)用出了錯都不知道哪里漏了fd。我這里把這些全部收口在一個類里。class EventLoop { public: EventLoop() { epfd_ epoll_create1(EPOLL_CLOEXEC); if (epfd_ 0) { throw std::runtime_error(epoll_create1 failed); } } ~EventLoop() { close(epfd_); } // 核心聲明注冊或更新某個fd關注的事件 void updateChannel(Channel* ch) { struct epoll_event ev; memset(ev, 0, sizeof(ev)); ev.events ch-events(); ev.data.ptr ch; // 關鍵把Channel指針直接掛在事件上 int op ch-isRegistered() ? EPOLL_CTL_MOD : EPOLL_CTL_ADD; if (epoll_ctl(epfd_, op, ch-fd(), ev) 0) { // 這里要格外小心ADD失敗時應該做清理和日志 } ch-setRegistered(true); } void removeChannel(Channel* ch) { // 使用EPOLL_CTL_DEL從epoll中摘除fd epoll_ctl(epfd_, EPOLL_CTL_DEL, ch-fd(), nullptr); ch-setRegistered(false); } void loop() { while (!quit_) { int nready epoll_wait(epfd_, events_, kMaxEvents, 1000); for (int i 0; i nready; i) { Channel* ch static_castChannel*(events_[i].data.ptr); uint32_t revents events_[i].events; ch-handleEvent(revents); } } } private: int epfd_; bool quit_ false; struct epoll_event events_[1024]; static const int kMaxEvents 1024; };這里有個設計細節(jié)很多人忽略為什么用epoll_event.data.ptr而不是data.fd因為事件處理的回調(diào)邏輯存在于Channel對象里如果你只存fd拿到事件后還得再找映射關系等于多一次查表。把Channel指針直接塞進data.ptr里epoll_wait()一回來就立刻拿到完整的處理對象省掉一層查找。這跟很多框架里把連接對象指針掛到事件上的做法一模一樣。另外注意epoll_create1(EPOLL_CLOEXEC)。很多老代碼用epoll_create(0)然后忘了設置FD_CLOEXEC一旦服務端程序fork子進程子進程里會意外繼承一個epoll實例fd泄漏問題就這么埋下了。個人建議所有創(chuàng)建fd的地方都要考慮CLOEXEC不只epollsocket創(chuàng)建時也一樣用SOCK_CLOEXEC。這是生產(chǎn)環(huán)境壓測過幾十萬連接后才會在意的細節(jié)本地寫著寫著可能根本發(fā)現(xiàn)不了。Channel的核心代碼也很短但要保證它足夠通用class Channel { public: Channel(int fd, uint32_t events, EventCallback readCb, EventCallback writeCb) : fd_(fd), events_(events), readCb_(std::move(readCb)), writeCb_(std::move(writeCb)) {} void handleEvent(uint32_t revents) { // 優(yōu)先處理異常事件 if (revents (EPOLLERR | EPOLLHUP | EPOLLRDHUP)) { if (closeCb_) closeCb_(); return; } if (revents EPOLLIN) { if (readCb_) readCb_(); } if (revents EPOLLOUT) { if (writeCb_) writeCb_(); } } int fd() const { return fd_; } uint32_t events() const { return events_; } bool isRegistered() const { return registered_; } void setRegistered(bool v) { registered_ v; } private: int fd_; uint32_t events_; bool registered_ false; EventCallback readCb_; EventCallback writeCb_; EventCallback closeCb_; };要重點提醒的是事件掩碼的判斷順序。EPOLLERR和EPOLLHUP并不需要你注冊epoll會自動上報所以handleEvent里第一步必須把它摘出來否則你永遠等不到正常的讀寫回調(diào)。EPOLLRDHUP表示對端正常關閉寫半?yún)^(qū)有的服務會在這一支里做對端關閉的清理能省掉一次無意義的recv。3.3 從新連接到業(yè)務分發(fā)Acceptor與TcpConnectionAcceptor做的事情很單純而且極重要它的可讀回調(diào)就是整個服務的入口。監(jiān)聽socket是可讀的說明有新的連接請求到達此時你調(diào)用accept4()取出新fd再把它包裝成TcpConnection注冊到EventLoop中。class Acceptor { public: Acceptor(EventLoop* loop, uint16_t port) : loop_(loop) { listenFd_ socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0); // 綁定端口、設置SO_REUSEADDR、監(jiān)聽的代碼省去 channel_ std::make_uniqueChannel( listenFd_, EPOLLIN, [this]() { handleNewConnection(); }, nullptr ); loop_-updateChannel(channel_.get()); } void handleNewConnection() { struct sockaddr_in peerAddr{}; socklen_t len sizeof(peerAddr); while (true) { int connFd accept4(listenFd_, (struct sockaddr*)peerAddr, len, SOCK_NONBLOCK | SOCK_CLOEXEC); if (connFd 0) { if (errno EAGAIN) break; // LT模式下一定要做這個判斷 // EMFILE、ECONNABORTED等錯誤分別處理 break; } auto conn std::make_sharedTcpConnection(loop_, connFd, peerAddr); // 連接對象交給連接管理器持有防止被析構(gòu) } } };兩個細節(jié)在這里值得停下來細說。第一accept()要用循環(huán)一次處理完當前已經(jīng)排隊的連接。高并發(fā)時可能同時到來幾十個連接請求如果你一次只accept一個就走剩下的連接會在內(nèi)核排隊等下次事件。多等一個epoll周期對延遲影響很大。第二connFd一定要設置非阻塞最好是accept4()直接帶SOCK_NONBLOCK|SOCK_CLOEXEC一步到位。因為在ET模式下你后面要循環(huán)讀數(shù)據(jù)非阻塞是必須的阻塞fd在循環(huán)讀不到數(shù)據(jù)時會卡死整個線程這是血淚教訓。TcpConnection的讀回調(diào)是業(yè)務的第一步。它先從socket讀到緩沖區(qū)然后走業(yè)務分發(fā)void TcpConnection::handleRead() { char buf[65536]; ssize_t n read(fd_, buf, sizeof(buf)); if (n 0) { inputBuffer_.append(buf, n); // 丟給線程池處理業(yè)務邏輯注意這里不能直接做耗時的業(yè)務 if (messageCb_) { messageCb_(shared_from_this(), inputBuffer_); } } else if (n 0) { // 對端關閉觸發(fā)連接清理回調(diào) if (closeCb_) closeCb_(); } else { if (errno ! EAGAIN errno ! EWOULDBLOCK) { // 真正的讀錯誤如ECONNRESET if (errorCb_) errorCb_(); } } }注意shared_from_this的用法TcpConnection必須繼承std::enable_shared_from_this否則你在回調(diào)里拿不到安全的shared_ptr連接對象可能在處理過程中被析構(gòu)懸空指針問題防不勝防。這是C寫網(wǎng)絡服務最容易出的內(nèi)存級bug。3.4 定時器與空閑連接管理Reactor架構(gòu)里最后一塊拼圖一個正經(jīng)的網(wǎng)絡服務離不開超時管理?？蛻舳诉B上了握完手發(fā)了一個請求之后就沒動靜了如果服務端不清理這個fd會一直占著連接數(shù)遲早被僵尸連接吃光。處理超時最優(yōu)雅的做法是把定時器也做成事件源。Linux提供了timerfd_create()你可以創(chuàng)建一個定時器fd并把它注冊到epoll里讓它參與事件循環(huán)。這樣定時器到期后會像一個普通fd的可讀事件一樣被epoll_wait喚醒代碼可以統(tǒng)一走Channel回調(diào)。int tfd timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK | TFD_CLOEXEC); struct itimerspec its{}; its.it_value {5, 0}; // 5秒后第一次到期 its.it_interval {5, 0}; // 之后每5秒到期一次 timerfd_settime(tfd, 0, its, nullptr); // 將這個tfd封裝成Channel注冊到EventLoop但是項目里如果只用timerfd做粗粒度心跳檢測還好要是業(yè)務大量依賴精確到毫秒的定時任務專門為每個task建一個timerfd就不合適了fd數(shù)量會失控。更實際的做法是在EventLoop里維護一個最小堆或時間輪每次epoll_wait之前計算最近的一個超時時間把超時作為epoll_wait的timeout參數(shù)傳進去epoll_wait返回后再檢查所有超時任務并執(zhí)行回調(diào)。這套做法復用能力強也避免額外fd開銷。我項目早期用的是timerfd后來定時器任務多了以后果斷換成了最小堆方案一下子清爽很多。空閑連接的判斷邏輯也很簡單每次連接上有讀寫活動時更新最后活躍時間定時器任務掃描時凡是過了閾值比如30秒還沒活動的連接直接調(diào)用close回調(diào)并且從EventLoop和連接管理器中雙重剔除。當連接管理器里只剩一堆死緩存時再想靠硬編碼去清理代價就大了。4. 實測中一定會踩的坑和排查技巧4.1 ET模式下的讀不完和數(shù)據(jù)殘留第一次把LT切換到ET大概率會遇到一個問題服務端處理完一批數(shù)據(jù)后下一次不觸發(fā)了客戶端卻還在等響應。原因就是我前面說的ET只在狀態(tài)變化時通知你讀數(shù)據(jù)時沒有把緩沖區(qū)的數(shù)據(jù)一次讀完剩下的數(shù)據(jù)憋在里面直到新數(shù)據(jù)到來才有可能觸發(fā)。解決這個問題的方法已經(jīng)約定俗成在ET模式下讀事件觸發(fā)后循環(huán)調(diào)用read直到返回EAGAIN。EAGAIN不是錯誤它表示當前已無數(shù)據(jù)可讀是讀干凈了的信號。寫事件同理寫緩沖區(qū)滿了以后ET模式不會再次觸發(fā)你需要在每次寫完數(shù)據(jù)后主動檢查緩沖區(qū)是否還有殘留有殘留就給fd注冊EPOLLOUT事件只有等到可寫事件觸發(fā)時才繼續(xù)把剩余數(shù)據(jù)寫完寫完再注銷EPOLLOUT。這套寫好一次、沒寫完再注冊、寫完注銷的狀態(tài)機邏輯是ET模式下最容易出bug的地方建議把讀寫流程精簡到極致再上ET。4.2 epoll驚群問題從多線程到EPOLLEXCLUSIVE多個線程或進程在同一個監(jiān)聽socket上同時調(diào)用epoll_wait當新連接到達時所有等待者都可能被喚醒但只有一個能成功accept這就是驚群。早期Linux上這個問題非常嚴重后來內(nèi)核引入了EPOLLEXCLUSIVE標志給event它能讓事件喚醒時只通知等待隊列里的一個線程從而解決大部分驚群問題。實際項目中還有另一個思路SO_REUSEPORT讓多個進程各自創(chuàng)建監(jiān)聽socket都綁定同一個端口內(nèi)核在連接到來時做負載均衡分配到不同的監(jiān)聽socket上。這樣每個進程各查各的epoll互不干擾在nginx這類多進程模型里是很常見的調(diào)度方式。不過SO_REUSEPORT在同機多進程場景里會帶來fd分發(fā)不均勻的可能性連接數(shù)來得很猛時內(nèi)核的hash可能傾斜需要配合定期重載或監(jiān)控調(diào)整。無論用哪種方案測試環(huán)境一定要模擬高并發(fā)驗證光看代碼是看不出隱藏問題的。4.3 事件回調(diào)里絕對不能做耗時操作這個坑我見過太多次了代碼邏輯看著沒問題壓測一上就卡成PPT。根源都是一樣的在Channel的可讀回調(diào)里直接做了數(shù)據(jù)庫查詢、文件IO、加密計算等耗時操作整個事件循環(huán)被拖住了。記住一個原則事件循環(huán)線程只做收發(fā)數(shù)據(jù)、編解碼、分發(fā)任務這幾件事。凡是可能阻塞超過毫秒級別的操作一律丟到線程池。這里還有一個細節(jié)線程池返回結(jié)果也要小心如果工作線程處理完業(yè)務后直接去調(diào)用TcpConnection的回寫方法這是典型的跨線程調(diào)用。如果此時工作線程持有鎖而主循環(huán)線程也在操作這個連接就會產(chǎn)生競態(tài)。成熟的方案是把寫回動作通過任務隊列放回EventLoop所在線程執(zhí)行這也是很多網(wǎng)絡框架里queueInLoop機制的核心作用。寫回必須由EventLoop線程執(zhí)行這是一個鐵律。4.4 蹚過的坑速查表從fd泄漏到EPOLLHUP把高頻踩坑整理成一張表排查時可以按圖索驥。這些坑有些是運行時才暴露的有些是壓測到臨界點才翻車的每一條我都付出過不小的代價。癥狀根因排查辦法進程fd數(shù)持續(xù)上漲不回收連接關閉后忘了從epoll刪除或close fd用ls /proc/進程pid/fd觀察fd數(shù)量結(jié)合日志看哪些連接沒走關閉流程高頻連接后出現(xiàn)段錯誤TcpConnection對象被提前釋放回調(diào)還在用確保連接類繼承enable_shared_from_this回調(diào)中全用shared_ptr持有必要時延遲釋放單線程Reactor偶發(fā)無響應某個handler中出現(xiàn)了阻塞調(diào)用用strace -p 進程號看卡在哪個系統(tǒng)調(diào)用上重點檢查SQL、磁盤IOET模式下偶發(fā)丟包讀事件到達后沒有循環(huán)讀到EAGAIN代碼里搜索read確認ET路徑有沒有循環(huán)沒循環(huán)的無腦加上epoll_wait頻繁返回但CPU極高LT模式下小包反復觸發(fā)每次只讀一點點轉(zhuǎn)換為ET模式或者每次讀事件至少讀完一次緩沖里所有數(shù)據(jù)連接close后仍接到EPOLLHUP事件對端異常關閉服務端沒及時處理掛起狀態(tài)在handleEvent里對EPOLLHUP分支立刻做清理別等可讀事件accept后新連接不工作accept出來的fd沒有改成非阻塞或沒有正確注冊進epoll檢查accept4的標志位并確認updateChannel里EPOLL_CTL_ADD執(zhí)行成功這幾條排查思路看起來零散但底層邏輯都是相通的網(wǎng)絡服務里的每一個fd、每一個事件都是一個狀態(tài)機任何環(huán)節(jié)漏了狀態(tài)轉(zhuǎn)移最終都會表現(xiàn)為連接卡住或者內(nèi)存瘋長。排查的時候先看fd有沒有被正確處置再看事件有沒有被正確分發(fā)最后才懷疑業(yè)務邏輯順序反了很容易兜圈子。4.5 從這套架構(gòu)出發(fā)的擴展方向和調(diào)試技巧到這里Epoll-Reactor模式的骨架和踩坑經(jīng)驗都已經(jīng)梳理得比較完整了。如果要再往深處走有幾個方向是這個模式天然適合擴展的在TcpConnection之上疊加一層編解碼器就能從TCP裸數(shù)據(jù)升級出HTTP、WebSocket或者自定義二進制協(xié)議Reactor框架本身完全不需要變動把連接狀態(tài)中的心跳檢測和重連機制抽成獨立服務做成一個獨立的子Reactor能進一步優(yōu)化整體連接管理能力針對大量只讀不寫的空閑連接可以引入智能關閉策略用時間輪管理空閑連接淘汰策略更精準。調(diào)試這套系統(tǒng)的時候我還想分享一個小技巧比任何日志都好使開啟內(nèi)核的網(wǎng)絡監(jiān)控功能。壓測時如果發(fā)現(xiàn)連接異常先看ss -tnp確認TCP狀態(tài)配合tcpdump抓包能立刻分清楚是服務端的epoll分發(fā)問題還是傳輸層的握手、丟包問題。代碼層面的日志不要只記錄業(yè)務信息要把每個連接的新建、可讀、關閉事件也記錄下鏈路一旦出問題你可以把一條連接的生命周期完整拼出來排查效率能高好幾倍。另外有條件的話用高并發(fā)的壓測工具在獨立機器上跑壓力測試不要在開發(fā)機上壓網(wǎng)絡協(xié)議棧的干擾項太多了。壓力和代碼調(diào)試一定要分開環(huán)境不然數(shù)據(jù)根本不可信你會被噪聲折磨到懷疑人生。這套架構(gòu)我從大文件傳輸服務、網(wǎng)關代理到協(xié)議測試工具前后用過不少次。每次寫新服務時我都是拿著同一個EventLoop骨架往里填不同的Handler和業(yè)務邏輯很快就能出一個可運行、可壓測的版本。相比從零開始堆代碼這種模式化的開發(fā)方式省下的不只是時間更是后期排障時的理智。