動如何用少量線程支撐海量并發(fā))
開頭Reactor模式幾乎是每個高并發(fā)網(wǎng)絡服務都繞不開的一個詞你在閱讀各種高性能框架源碼時總能撞見它的影子。它不是一個具體的框架或庫而是一套事件驅(qū)動并發(fā)模型核心就一句話用極少的線程配合非阻塞IO與事件分發(fā)支撐海量連接。換句話說服務端不用再“一個連接配一個線程”而是讓一個或少數(shù)幾個線程同時盯著成千上萬個事件誰的事件就緒了就派發(fā)給對應的處理器干活。這套模式能解決的問題非常直接高并發(fā)下線程太多導致的內(nèi)存膨脹、上下文切換開銷、CPU空轉浪費。適合正在做網(wǎng)絡服務、網(wǎng)關、IM系統(tǒng)、消息推送、游戲服務端的人閱讀。如果你正準備寫一個面向長連接的高性能服務或者想理解手頭框架的事件循環(huán)是怎么設計出來的這篇文章就是照著你這類場景寫的。在往下拆之前先把話說透Reactor模式的本質(zhì)不是技術口號而是一種把“等待”集中起來管理的思路。誰能把等待管理得更好誰就能在同樣的服務器資源下扛住更大的并發(fā)量。下面我從根源講起逐步拆到代碼實現(xiàn)和踩坑經(jīng)驗。1. 為什么服務端都要用Reactor這套思路1.1 傳統(tǒng)多線程阻塞模型的瓶頸很多人剛接觸網(wǎng)絡編程時最容易上手的就是阻塞IO加多線程主線程accept到一個連接就丟給一個線程去處理這個線程在這個連接沒有數(shù)據(jù)可讀時會一直阻塞在read上直到客戶端發(fā)來數(shù)據(jù)。這種模式在連接量少的時候完全沒問題代碼直觀調(diào)試方便。但連接數(shù)一旦上來問題就暴露了每個連接占一個線程線程本身要占用幾MB的?？臻g雖然是虛擬內(nèi)存但大量線程的創(chuàng)建銷毀也會消耗資源一萬個連接就意味著至少一萬個線程光是線程調(diào)度就讓CPU疲于奔命。絕大多數(shù)連接是“掛著不動的”比如客戶端連上服務端后長期不發(fā)數(shù)據(jù)。這種情況下線程阻塞在read上完全是空等CPU卻要反復切換來切換去資源被白白浪費。每來一個連接就創(chuàng)建線程、斷開就銷毀線程這種高頻創(chuàng)建銷毀會帶來巨大的系統(tǒng)調(diào)用開銷和GC壓力。我記得以前做過一個內(nèi)部壓測用最樸素的“每連接一線程”模型模擬一萬個長連接客戶端結果機器還沒到2000連接時負載就已經(jīng)被線程切換打到很高了而真正有數(shù)據(jù)吞吐的連接還不到5%。這個場景讓我徹底明白了一個道理高并發(fā)服務的敵人從來不是數(shù)據(jù)量而是海量空閑連接。1.2 非阻塞IO與事件循環(huán)如何改變游戲規(guī)則既然阻塞在等待上的線程是浪費那能不能讓少量線程“同時等”很多連接呢操作系統(tǒng)早就給了答案非阻塞IO加多路復用接口。所謂多路復用就是把“等待是否可讀可寫”這個動作統(tǒng)一丟給內(nèi)核去監(jiān)聽一個線程可以同時監(jiān)聽幾百上千個socket哪個socket就緒了內(nèi)核就告訴你哪一個你再去處理它。Reactor模式正是在這個基礎上搭建的。它把整個服務端程序抽象成事件循環(huán)Event Loop加回調(diào)分發(fā)事件循環(huán)負責反復調(diào)用多路復用接口比如select、poll、epoll來獲取就緒事件然后把事件分發(fā)給對應的事件處理器處理器執(zhí)行完業(yè)務邏輯后回到循環(huán)繼續(xù)等待下一批事件。這就像餐廳里只有一個大管家站在門口集中記錄所有客人的需求。哪個桌子的菜好了、哪桌要加水他統(tǒng)一盯著叫對應的服務員去處理而不是每個桌子都配一個服務員干站著等菜。這樣一來服務員數(shù)量大幅下降餐廳卻運轉得更快。理解了這層你再看“Reactor模式”這個詞就會明白它根本不是某個特定框架的專利而是一種從阻塞等待轉向事件驅(qū)動、從每個連接一條執(zhí)行路徑轉向集中分發(fā)的基本思路。2. Reactor模式的核心角色與工作鏈路2.1 四個核心角色Reactor模式之所以能被反復講是因為它把并發(fā)模型里的責任分得非常清楚。實現(xiàn)一個Reactor至少需要四個角色。第一個角色叫事件源也就是觸發(fā)事件的東西最常見的是一堆socket連接。它們本身不產(chǎn)生業(yè)務邏輯只是信號的來源。第二個角色叫多路復用器負責把所有事件源同時掛在系統(tǒng)監(jiān)聽上持續(xù)等待事件到來。在Linux環(huán)境里這個角色就是epoll在Java里面它對應的是Selector的底層封裝。第三個角色叫事件分發(fā)器也就是那個大管家負責從多路復用器里拿到就緒事件的列表按事件類型找到對應的處理器把事件交給它。最后一個角色叫事件處理器是你業(yè)務邏輯真正落腳的地方比如一個連接可讀了處理器負責把數(shù)據(jù)讀出來、解析協(xié)議、返回響應。為了簡化很多實現(xiàn)把多路復用器和事件分發(fā)器合在一起統(tǒng)稱為Reactor也就是事件循環(huán)本身。你聽別人說“跑在Reactor里”指的就是代碼運行在事件循環(huán)線程上。2.2 一次事件從發(fā)生到處理完畢的完整鏈路咱們拿一個最簡單的場景走一遍流程某客戶端向服務端發(fā)送了一條數(shù)據(jù)。第一步客戶端的數(shù)據(jù)到達服務端的socket緩沖區(qū)此時這個socket成為“可讀事件源”。第二步事件循環(huán)中阻塞在epoll_wait上的調(diào)用立刻返回拿到一個就緒事件列表里面包含這個可讀的socket。第三步分發(fā)器根據(jù)這個socket上注冊的處理器類型判斷這是新連接還是已有連接。如果是新連接就走Acceptor邏輯調(diào)用accept收下連接如果是已有連接就調(diào)用對應的讀事件處理器。第四步讀事件處理器從socket里非阻塞讀出數(shù)據(jù)進行協(xié)議解碼、業(yè)務處理然后把要返回的數(shù)據(jù)寫入發(fā)送緩沖區(qū)并讓事件循環(huán)繼續(xù)監(jiān)聽這個socket的可寫狀態(tài)。第五步當socket可寫時觸發(fā)寫事件處理器把發(fā)送緩沖區(qū)里的數(shù)據(jù)真正flush出去。整套流程看下來處理是分批的沒有一個線程一直在某個連接上死等。數(shù)據(jù)沒到的時候這個socket在事件循環(huán)里只是一個普通的監(jiān)聽項不占任何業(yè)務線程。2.3 為什么說回調(diào)是Reactor的心臟Reactor模式之所以難寫難在回調(diào)。事件循環(huán)把“什么時候處理”的權力拿走了業(yè)務邏輯被打散成一個個事件處理的片段一旦收到事件就必須把活干完因為干不完會影響后面所有事件的處理。這種編程方式跟傳統(tǒng)的順序式編程完全不同。順序式編程里你可以讀數(shù)據(jù)、等結果、再返回邏輯是直的Reactor里你不能等因為等待會讓事件循環(huán)卡死。所以“事件來了就處理處理完立刻返回不能阻塞”是核心紀律。我見過很多初學者把數(shù)據(jù)庫查詢、第三方HTTP調(diào)用、耗時計算直接寫進事件處理器里結果壓測時整個服務表現(xiàn)為間歇性卡頓單個慢請求拖垮所有連接。后來大家約定俗成的做法是把耗時操作丟給專門的業(yè)務線程池事件處理器只做接收、Dispatch和快速返回。3. 三種雷打不動的Reactor變體3.1 單線程Reactor最純粹的事件驅(qū)動最簡單的改造方案是單線程Reactor。整個進程只有一個事件循環(huán)線程它做多路復用、分發(fā)也做大部分業(yè)務處理。這個方案的典型代表你肯定見過很多高性能緩存服務和一些內(nèi)存數(shù)據(jù)庫的單線程事件模型就是這么設計的大名鼎鼎的“單線程扛十萬連接”說的就是這種形態(tài)。單線程Reactor的優(yōu)勢非常突出。首先沒有鎖整個進程內(nèi)所有狀態(tài)從事件循環(huán)的角度看都是單線程訪問的不需要考慮并發(fā)競爭很多bug天然不存在。其次代碼路徑簡單沒有線程間通信沒有共享狀態(tài)同步調(diào)試起來非常舒服。再有它的極限吞吐能力在IO密集型短任務場景下并不差因為CPU切換和鎖競爭的開銷幾乎為零。但它的短板也很致命一個事件處理器里如果出現(xiàn)了任何阻塞操作整個服務就卡住了。這就像整個餐廳只有一個大管家他既要接客又要傳菜哪怕有一個人在結賬時磨蹭半天后面所有客人都得等著。所以單線程Reactor只適合業(yè)務處理極快、沒有慢IO的場景。3.2 主從Reactor讓接受連接和讀寫事件分離連接數(shù)一旦到幾萬單線程Reactor就開始吃力。問題集中在幾個點上所有新連接都要在同一個事件循環(huán)里accept、分發(fā)讀寫事件還要處理業(yè)務CPU容易跑滿更麻煩的是當事件循環(huán)正在處理某個長任務時新連接沒人響應客戶端很容易超時。主從Reactor的改造思路是把接受的活和讀寫的活分開。一組線程池專門負責監(jiān)聽listen socket上的新連接事件accept之后把新連接注冊到另一組線程池里后者負責這些連接后續(xù)所有的讀寫事件和業(yè)務處理。主線程池可以只有一個從線程池通常有多個避免單個事件循環(huán)過載。這樣連接一旦建立成功就不會因為“主線程太忙accept不過來”而影響已有連接的數(shù)據(jù)處理。我在實際項目里很偏愛這個結構主線監(jiān)聽鎖競爭幾乎為零每個從線程的事件循環(huán)各自管一批連接互不干擾只要把連接分配做得平均CPU就能被吃滿。很多成熟網(wǎng)絡框架的后續(xù)版本基本都演化成了這個模型主線程專職接待工作線程專職跑業(yè)務分工明確。3.3 Reactor加業(yè)務線程池最終形態(tài)主從Reactor解決了連接數(shù)量和事件循環(huán)卡頓的問題但業(yè)務處理如果很耗時比如需要查數(shù)據(jù)庫、調(diào)外部服務、做復雜計算這些操作如果直接放在從線程的處理器里仍然會阻塞那個事件循環(huán)拖累它名下幾百個連接。所以主從Reactor再演進一檔事件循環(huán)只做IO讀取、編解碼和數(shù)據(jù)分發(fā)得到完整業(yè)務請求后把任務丟給一個專門的后置業(yè)務線程池去執(zhí)行。業(yè)務線程池的處理結果通過異步回調(diào)方式送回事件循環(huán)再走寫事件把響應發(fā)出去。這樣一來事件循環(huán)線程永遠不會被慢業(yè)務阻塞而業(yè)務線程池只要能扛得住并發(fā)就可以用可配置的線程數(shù)量從容處理各種耗時操作。這一檔的代價是模型復雜度明顯上升跨線程投遞任務要處理并發(fā)、回調(diào)要保證線程安全、業(yè)務線程池要設計合理的隊列長度和拒絕策略。所以在小規(guī)模項目里不要一上來就上這套先分清瓶頸到底在哪再決定要不要加復雜度。下面用一個表格把三種形態(tài)的關鍵點擺在臺面上形態(tài)事件循環(huán)數(shù)量業(yè)務處理位置適合場景主要風險單線程Reactor1事件循環(huán)內(nèi)高吞吐、短任務、IO密集任何阻塞都會全局卡死主從Reactor1個主 N個從從事件循環(huán)內(nèi)大量連接、處理偏輕量慢業(yè)務仍會拖垮單事件循環(huán)主從Reactor 業(yè)務線程池1個主 N個從獨立業(yè)務線程池混合業(yè)務、含慢操作線程安全與復雜度顯著上升4. 手寫一個能跑的極簡ReactorLinux epoll路徑4.1 頂層骨架事件循環(huán)跑起來理論講再多都不如親手寫一個極簡Reactor來得直觀。這里我用類C的偽代碼風格展示核心結構主要為了體現(xiàn)出Reactor模式的骨架方便你遷移到任何語言。先看頂層事件循環(huán)。它的工作就是創(chuàng)建epoll實例往里面注冊事件源然后無限循環(huán)地調(diào)用epoll_wait拿到就緒事件后分發(fā)。// 偽代碼極簡Reactor事件循環(huán) EventLoop* loop event_loop_new(); // 注冊事件回調(diào)比如一個可讀事件對應一個handler loop-register_handler(socket_fd, EVENT_READ, on_read, context); while (loop-running) { // 阻塞等待事件就緒超時時間自行設定 struct epoll_event events[1024]; int n epoll_wait(loop-epoll_fd, events, 1024, -1); for (int i 0; i n; i) { EventHandler* h (EventHandler*)events[i].data.ptr; // 這一步就是“分發(fā)” h-handle_event(events[i].events, h-context); } }這段代碼看起來短卻包含了Reactor最常見的三個動作等待、分發(fā)、回調(diào)。實際工程里會在register_handler時把fd設置成非阻塞并把它和對應的handler綁定在一起放到一個數(shù)據(jù)結構里方便分發(fā)時直接找到處理器。4.2 事件處理器接口讓代碼可插拔事件循環(huán)不該知道業(yè)務細節(jié)所以需要定義統(tǒng)一的事件處理器接口。無論是監(jiān)聽新連接、讀取數(shù)據(jù)、寫出數(shù)據(jù)都是實現(xiàn)同一個接口// 事件處理器抽象接口 typedef struct EventHandler { void (*handle_event)(uint32_t events, void* context); void* context; // 保存socket、協(xié)議狀態(tài)等數(shù)據(jù) } EventHandler;新連接接入的邏輯在Reactor里通常叫Acceptor它本質(zhì)上是監(jiān)聽socket的一個讀事件處理器當listen socket可讀時說明有新連接來敲門于是調(diào)用accept把連接收下再給新連接創(chuàng)建對應的讀寫處理器并注冊到事件循環(huán)里。// 偽代碼Acceptor只負責收新連接 void accept_handler(uint32_t events, void* context) { Acceptor* acc (Acceptor*)context; int client_fd accept(acc-listen_fd, NULL, NULL); if (client_fd 0) { set_nonblocking(client_fd); // 關鍵為新連接注冊讀事件處理器 EventHandler* h create_read_handler(client_fd); acc-loop-register_handler(client_fd, EVENT_READ | EVENT_WRITE, h, h); } }這段代碼里最容易被忽略的是set_nonblocking。Reactor模式下所有IO都必須是非阻塞因為事件循環(huán)只負責通知你“可讀了”如果你的read操作因為數(shù)據(jù)沒到齊而阻塞那事件循環(huán)就卡死了。這也是工程上一個非常典型的隱患事件循環(huán)里的fd忘記設置非阻塞低峰期一切正常高峰期一壓測就集體掛起。4.3 從單線程到多線程快速演進思路極簡版單線程Reactor寫出來之后升級成多線程Reactor的思路其實非常順開多個事件循環(huán)線程每個線程獨立跑一個epoll實例主線程的Acceptor收到新連接后按某種負載均衡策略比如輪詢、按連接數(shù)最少把連接均勻分到各個事件循環(huán)線程去注冊。這樣每個事件循環(huán)只處理自己名下的一部分連接彼此之間沒有共享狀態(tài)也不需要加鎖。我在實際項目里用過一個更省事的分配方法不搞復雜負載均衡直接用原子計數(shù)器做round-robin每一萬個連接跑下來分布非常均勻代碼也就十幾行。復雜的調(diào)度策略在連接數(shù)分配這個場景下性價比很低真出現(xiàn)某個事件循環(huán)負載偏高時通常是因為業(yè)務分配不均而不是連接分配不勻。如果你想在這一版基礎上繼續(xù)充分壓榨CPU就把業(yè)務處理從事件循環(huán)里剝離加一個業(yè)務線程池。事件循環(huán)讀到完整請求后封裝成任務投遞給線程池線程池處理完成后通過內(nèi)部隊列把結果投回事件循環(huán)由它觸發(fā)寫事件向外發(fā)數(shù)據(jù)。這個結構就是目前主流網(wǎng)絡框架的最終形態(tài)理解之后再看任何開源框架你都不會迷路。5. 實操中反復踩過的坑5.1 回調(diào)里做了阻塞操作事件循環(huán)直接卡死這是Reactor模式殺傷力最大的一個坑幾乎每個寫過事件驅(qū)動服務的人都中過招。某次我接手一個線上服務現(xiàn)象是每天下午高峰時段會莫名出現(xiàn)幾秒鐘的全局限流排查了很久最后發(fā)現(xiàn)是某個接口寫了個同步的數(shù)據(jù)庫查詢直接放在事件處理器里。高峰時數(shù)據(jù)庫稍微慢了一下一個事件循環(huán)被卡住它手底下幾千條連接全部跟著延遲。排查方法很簡單在事件循環(huán)里給業(yè)務處理加上日志記錄每次處理的耗時如果出現(xiàn)毫秒級的耗時波動逐層往下找?；蛘咧苯釉谑录h(huán)里臨時引入一個監(jiān)控計數(shù)器每次循環(huán)記錄耗時分布。一旦發(fā)現(xiàn)某個處理器的耗時明顯偏高立刻就能鎖定問題。5.2 同一個連接上的讀寫事件互相餓死事件循環(huán)里一個fd可以同時監(jiān)聽讀事件和寫事件。如果寫事件處理器里做了大數(shù)據(jù)量發(fā)送恰巧發(fā)送緩沖區(qū)一直不滿那么寫事件會反復觸發(fā)占滿整個事件循環(huán)的處理時間導致同fd的讀事件遲遲得不到處理。這種問題在壓測大包流量時非常常見。常規(guī)解法是分級處理寫事件一旦觸發(fā)把待發(fā)數(shù)據(jù)盡量一次性寫完如果沒寫完也不要一條路寫到黑而是控制單次發(fā)送的數(shù)據(jù)量或者把寫事件從監(jiān)聽列表里暫時摘除等下一輪再注冊。核心原則是每個事件的處理時間應當被控制在很短的范圍內(nèi)你永遠不知道同一個循環(huán)里其他幾百上千個事件在等著你。5.3 連接分發(fā)時的驚群問題在多線程Reactor里如果主線程accept新連接后立即把連接注冊到某個事件循環(huán)看起來沒什么問題。但如果多個事件循環(huán)線程同時都監(jiān)聽同一個listen socket甚至每個線程都調(diào)用epoll_wait等待同一個listen fd那就可能出現(xiàn)“驚群”一個新連接進來內(nèi)核喚醒所有等待的線程但只有一個線程能成功accept其余線程白白空轉一圈。這個坑我剛接觸多Reactor時踩得很深后來特意研究了一下解決方案不外乎兩種要么讓listen fd只由一個主Reactor獨占accept之后再分發(fā)給其他Reactor要么使用內(nèi)核提供的負載均衡機制來避免驚群。對于絕大多數(shù)應用第一種方案已經(jīng)足夠為了那點accept性能去引入復雜的內(nèi)核特性得不償失。5.4 線程安全共享狀態(tài)比想象中更容易臟多線程Reactor最讓開發(fā)者頭疼的就是線程安全。事件循環(huán)線程之間通常不共享連接但業(yè)務層數(shù)據(jù)是共享的比如在線用戶表、房間列表、全局計數(shù)器。如果你在多個事件循環(huán)線程中直接修改這些共享狀態(tài)就會出現(xiàn)詭異的偶發(fā)問題好好的session突然不見了、用戶狀態(tài)偶爾對不上。經(jīng)驗做法是能按連接拆分的數(shù)據(jù)就盡量按連接拆分事件循環(huán)內(nèi)部只保存連接自己的狀態(tài)任何跨連接的數(shù)據(jù)操作都走統(tǒng)一的服務層接口并在該接口內(nèi)部完成加鎖。不要指望“這段代碼不會同時執(zhí)行”在不知被多少事件循環(huán)線程同時跑著的代碼里這句話永遠是錯的。5.5 背壓問題寫不出去怎么辦當服務端處理速度跟不上客戶端發(fā)送速度時你很快會遇到一個棘手的問題數(shù)據(jù)讀進來業(yè)務處理不過來了往終端或下游寫的時候發(fā)送緩沖區(qū)被填滿再繼續(xù)寫就會阻塞。Reactor模式下你沒法阻塞等待因為這會卡死事件循環(huán)。這時候必須建立背壓機制。常見的做法是為每個連接維護一個發(fā)送隊列數(shù)據(jù)量超過閾值時丟棄或拒絕新請求必要時直接斷掉超限連接。千萬不要無腦擴大發(fā)送緩沖區(qū)內(nèi)存是有限的一個連接撐爆內(nèi)存往往就是從“隊列無限增長”開始的。我在壓測時曾經(jīng)見過因為發(fā)送隊列沒有上限單連接堆積幾GB數(shù)據(jù)把服務打OOM的慘案。下面把這些問題整理成一張速查表方便你排查時對照現(xiàn)象根因快速處理方向所有連接周期性卡頓事件循環(huán)里出現(xiàn)阻塞操作定位慢處理器移出事件循環(huán)單連接性能差讀寫事件互相搶時間片限制單次處理量摘除事件監(jiān)聽多個事件循環(huán)同時空轉共有fd觸發(fā)驚群獨立listen線程accept后分發(fā)偶發(fā)數(shù)據(jù)錯亂共享狀態(tài)未加鎖隔離連接狀態(tài)統(tǒng)一服務層內(nèi)存持續(xù)上漲發(fā)送隊列無上限增加背壓控制異常斷連6. Reactor與Proactor的邊界選型時別搞混6.1 Reactor和Proactor到底差在哪Reactor和Proactor常常被放在一起比較但它們的差別其實非常本質(zhì)。Reactor是同步IO多路復用模式內(nèi)核通知你“可以讀了”你還要自己去調(diào)用read讀取數(shù)據(jù)讀取動作由用戶線程完成而Proactor是異步IO模式操作系統(tǒng)幫你把數(shù)據(jù)讀入指定的緩沖區(qū)讀完了再通知你“數(shù)據(jù)已經(jīng)放好了拿去用吧”。拿吃飯打比方Reactor模式是服務員告訴你“你的菜好啦請到取餐口取”你還要自己走過去端過來Proactor模式是服務員直接把菜端到你桌上你再掏筷子吃。兩者都是異步解耦但一個的“干活”動作還在用戶手里另一個的“干活”動作已經(jīng)由系統(tǒng)代勞了。實際工程里Proactor聽起來更省心但它要求操作系統(tǒng)提供良好的異步IO支持而且對“一次完整的讀寫”調(diào)度要求更高實現(xiàn)復雜度通常比Reactor高出一個數(shù)量級。這也是為什么大多數(shù)跨平臺網(wǎng)絡框架會優(yōu)先選擇Reactor只在特定平臺上充分利用系統(tǒng)異步IO接口。6.2 結合場景判斷該不該上Reactor選型時我給的建議是這樣的如果你的服務是短連接、事務型一次請求處理完就關閉并發(fā)量一般那完全不需要上Reactor直接用線程池阻塞模型即可代碼寫起來舒服得多。如果你的服務要面對長連接、海量連接、大部分連接長期掛機那Reactor是最穩(wěn)的底座單線程起步壓測后發(fā)現(xiàn)瓶頸再演進成主從結構逐步加復雜度。如果你的業(yè)務大量包含耗時操作比如查數(shù)據(jù)庫、調(diào)外部服務千萬別把所有邏輯都塞進事件循環(huán)要么上業(yè)務線程池要么干脆換異步等待模型。讓事件循環(huán)保持“輕載”是Reactor模式能長期穩(wěn)定運轉的核心原則。選型沒有絕對的正確答案核心是看你的瓶頸是連接數(shù)、吞吐量還是單請求耗時。把瓶頸想清楚了選型就水到渠成。結尾用了這么多年Reactor模式我自己最深的體會是它的門檻不在于理解那張經(jīng)典架構圖而在于你能不能守住“事件循環(huán)里不做重活”這條底線。架構圖畫起來誰都會真正難的是每時每刻都在提醒自己所有阻塞都必須從事件循環(huán)里剝離出去。另一個想說的小技巧如果你想快速驗證自己對Reactor的理解不要只讀框架源碼試著用你熟悉的語言照著上面的骨架寫一個能支撐幾百并發(fā)的最小實現(xiàn)。不用支持太多功能只要能完整走一遍accept、read、write事件分布鏈路你對這個模式的感受就會完全不同。寫壞了也沒關系踩過那幾個坑的人才是真正能把它用好的人。 Reactor模式詳解：事件驅(qū)動如何用少量線程支撐海量并發(fā)
開頭Reactor模式幾乎是每個高并發(fā)網(wǎng)絡服務都繞不開的一個詞你在閱讀各種高性能框架源碼時總能撞見它的影子。它不是一個具體的框架或庫而是一套事件驅(qū)動并發(fā)模型核心就一句話用極少的線程配合非阻塞IO與事件分發(fā)支撐海量連接。換句話說服務端不用再“一個連接配一個線程”而是讓一個或少數(shù)幾個線程同時盯著成千上萬個事件誰的事件就緒了就派發(fā)給對應的處理器干活。這套模式能解決的問題非常直接高并發(fā)下線程太多導致的內(nèi)存膨脹、上下文切換開銷、CPU空轉浪費。適合正在做網(wǎng)絡服務、網(wǎng)關、IM系統(tǒng)、消息推送、游戲服務端的人閱讀。如果你正準備寫一個面向長連接的高性能服務或者想理解手頭框架的事件循環(huán)是怎么設計出來的這篇文章就是照著你這類場景寫的。在往下拆之前先把話說透Reactor模式的本質(zhì)不是技術口號而是一種把“等待”集中起來管理的思路。誰能把等待管理得更好誰就能在同樣的服務器資源下扛住更大的并發(fā)量。下面我從根源講起逐步拆到代碼實現(xiàn)和踩坑經(jīng)驗。1. 為什么服務端都要用Reactor這套思路1.1 傳統(tǒng)多線程阻塞模型的瓶頸很多人剛接觸網(wǎng)絡編程時最容易上手的就是阻塞IO加多線程主線程accept到一個連接就丟給一個線程去處理這個線程在這個連接沒有數(shù)據(jù)可讀時會一直阻塞在read上直到客戶端發(fā)來數(shù)據(jù)。這種模式在連接量少的時候完全沒問題代碼直觀調(diào)試方便。但連接數(shù)一旦上來問題就暴露了每個連接占一個線程線程本身要占用幾MB的?？臻g雖然是虛擬內(nèi)存但大量線程的創(chuàng)建銷毀也會消耗資源一萬個連接就意味著至少一萬個線程光是線程調(diào)度就讓CPU疲于奔命。絕大多數(shù)連接是“掛著不動的”比如客戶端連上服務端后長期不發(fā)數(shù)據(jù)。這種情況下線程阻塞在read上完全是空等CPU卻要反復切換來切換去資源被白白浪費。每來一個連接就創(chuàng)建線程、斷開就銷毀線程這種高頻創(chuàng)建銷毀會帶來巨大的系統(tǒng)調(diào)用開銷和GC壓力。我記得以前做過一個內(nèi)部壓測用最樸素的“每連接一線程”模型模擬一萬個長連接客戶端結果機器還沒到2000連接時負載就已經(jīng)被線程切換打到很高了而真正有數(shù)據(jù)吞吐的連接還不到5%。這個場景讓我徹底明白了一個道理高并發(fā)服務的敵人從來不是數(shù)據(jù)量而是海量空閑連接。1.2 非阻塞IO與事件循環(huán)如何改變游戲規(guī)則既然阻塞在等待上的線程是浪費那能不能讓少量線程“同時等”很多連接呢操作系統(tǒng)早就給了答案非阻塞IO加多路復用接口。所謂多路復用就是把“等待是否可讀可寫”這個動作統(tǒng)一丟給內(nèi)核去監(jiān)聽一個線程可以同時監(jiān)聽幾百上千個socket哪個socket就緒了內(nèi)核就告訴你哪一個你再去處理它。Reactor模式正是在這個基礎上搭建的。它把整個服務端程序抽象成事件循環(huán)Event Loop加回調(diào)分發(fā)事件循環(huán)負責反復調(diào)用多路復用接口比如select、poll、epoll來獲取就緒事件然后把事件分發(fā)給對應的事件處理器處理器執(zhí)行完業(yè)務邏輯后回到循環(huán)繼續(xù)等待下一批事件。這就像餐廳里只有一個大管家站在門口集中記錄所有客人的需求。哪個桌子的菜好了、哪桌要加水他統(tǒng)一盯著叫對應的服務員去處理而不是每個桌子都配一個服務員干站著等菜。這樣一來服務員數(shù)量大幅下降餐廳卻運轉得更快。理解了這層你再看“Reactor模式”這個詞就會明白它根本不是某個特定框架的專利而是一種從阻塞等待轉向事件驅(qū)動、從每個連接一條執(zhí)行路徑轉向集中分發(fā)的基本思路。2. Reactor模式的核心角色與工作鏈路2.1 四個核心角色Reactor模式之所以能被反復講是因為它把并發(fā)模型里的責任分得非常清楚。實現(xiàn)一個Reactor至少需要四個角色。第一個角色叫事件源也就是觸發(fā)事件的東西最常見的是一堆socket連接。它們本身不產(chǎn)生業(yè)務邏輯只是信號的來源。第二個角色叫多路復用器負責把所有事件源同時掛在系統(tǒng)監(jiān)聽上持續(xù)等待事件到來。在Linux環(huán)境里這個角色就是epoll在Java里面它對應的是Selector的底層封裝。第三個角色叫事件分發(fā)器也就是那個大管家負責從多路復用器里拿到就緒事件的列表按事件類型找到對應的處理器把事件交給它。最后一個角色叫事件處理器是你業(yè)務邏輯真正落腳的地方比如一個連接可讀了處理器負責把數(shù)據(jù)讀出來、解析協(xié)議、返回響應。為了簡化很多實現(xiàn)把多路復用器和事件分發(fā)器合在一起統(tǒng)稱為Reactor也就是事件循環(huán)本身。你聽別人說“跑在Reactor里”指的就是代碼運行在事件循環(huán)線程上。2.2 一次事件從發(fā)生到處理完畢的完整鏈路咱們拿一個最簡單的場景走一遍流程某客戶端向服務端發(fā)送了一條數(shù)據(jù)。第一步客戶端的數(shù)據(jù)到達服務端的socket緩沖區(qū)此時這個socket成為“可讀事件源”。第二步事件循環(huán)中阻塞在epoll_wait上的調(diào)用立刻返回拿到一個就緒事件列表里面包含這個可讀的socket。第三步分發(fā)器根據(jù)這個socket上注冊的處理器類型判斷這是新連接還是已有連接。如果是新連接就走Acceptor邏輯調(diào)用accept收下連接如果是已有連接就調(diào)用對應的讀事件處理器。第四步讀事件處理器從socket里非阻塞讀出數(shù)據(jù)進行協(xié)議解碼、業(yè)務處理然后把要返回的數(shù)據(jù)寫入發(fā)送緩沖區(qū)并讓事件循環(huán)繼續(xù)監(jiān)聽這個socket的可寫狀態(tài)。第五步當socket可寫時觸發(fā)寫事件處理器把發(fā)送緩沖區(qū)里的數(shù)據(jù)真正flush出去。整套流程看下來處理是分批的沒有一個線程一直在某個連接上死等。數(shù)據(jù)沒到的時候這個socket在事件循環(huán)里只是一個普通的監(jiān)聽項不占任何業(yè)務線程。2.3 為什么說回調(diào)是Reactor的心臟Reactor模式之所以難寫難在回調(diào)。事件循環(huán)把“什么時候處理”的權力拿走了業(yè)務邏輯被打散成一個個事件處理的片段一旦收到事件就必須把活干完因為干不完會影響后面所有事件的處理。這種編程方式跟傳統(tǒng)的順序式編程完全不同。順序式編程里你可以讀數(shù)據(jù)、等結果、再返回邏輯是直的Reactor里你不能等因為等待會讓事件循環(huán)卡死。所以“事件來了就處理處理完立刻返回不能阻塞”是核心紀律。我見過很多初學者把數(shù)據(jù)庫查詢、第三方HTTP調(diào)用、耗時計算直接寫進事件處理器里結果壓測時整個服務表現(xiàn)為間歇性卡頓單個慢請求拖垮所有連接。后來大家約定俗成的做法是把耗時操作丟給專門的業(yè)務線程池事件處理器只做接收、Dispatch和快速返回。3. 三種雷打不動的Reactor變體3.1 單線程Reactor最純粹的事件驅(qū)動最簡單的改造方案是單線程Reactor。整個進程只有一個事件循環(huán)線程它做多路復用、分發(fā)也做大部分業(yè)務處理。這個方案的典型代表你肯定見過很多高性能緩存服務和一些內(nèi)存數(shù)據(jù)庫的單線程事件模型就是這么設計的大名鼎鼎的“單線程扛十萬連接”說的就是這種形態(tài)。單線程Reactor的優(yōu)勢非常突出。首先沒有鎖整個進程內(nèi)所有狀態(tài)從事件循環(huán)的角度看都是單線程訪問的不需要考慮并發(fā)競爭很多bug天然不存在。其次代碼路徑簡單沒有線程間通信沒有共享狀態(tài)同步調(diào)試起來非常舒服。再有它的極限吞吐能力在IO密集型短任務場景下并不差因為CPU切換和鎖競爭的開銷幾乎為零。但它的短板也很致命一個事件處理器里如果出現(xiàn)了任何阻塞操作整個服務就卡住了。這就像整個餐廳只有一個大管家他既要接客又要傳菜哪怕有一個人在結賬時磨蹭半天后面所有客人都得等著。所以單線程Reactor只適合業(yè)務處理極快、沒有慢IO的場景。3.2 主從Reactor讓接受連接和讀寫事件分離連接數(shù)一旦到幾萬單線程Reactor就開始吃力。問題集中在幾個點上所有新連接都要在同一個事件循環(huán)里accept、分發(fā)讀寫事件還要處理業(yè)務CPU容易跑滿更麻煩的是當事件循環(huán)正在處理某個長任務時新連接沒人響應客戶端很容易超時。主從Reactor的改造思路是把接受的活和讀寫的活分開。一組線程池專門負責監(jiān)聽listen socket上的新連接事件accept之后把新連接注冊到另一組線程池里后者負責這些連接后續(xù)所有的讀寫事件和業(yè)務處理。主線程池可以只有一個從線程池通常有多個避免單個事件循環(huán)過載。這樣連接一旦建立成功就不會因為“主線程太忙accept不過來”而影響已有連接的數(shù)據(jù)處理。我在實際項目里很偏愛這個結構主線監(jiān)聽鎖競爭幾乎為零每個從線程的事件循環(huán)各自管一批連接互不干擾只要把連接分配做得平均CPU就能被吃滿。很多成熟網(wǎng)絡框架的后續(xù)版本基本都演化成了這個模型主線程專職接待工作線程專職跑業(yè)務分工明確。3.3 Reactor加業(yè)務線程池最終形態(tài)主從Reactor解決了連接數(shù)量和事件循環(huán)卡頓的問題但業(yè)務處理如果很耗時比如需要查數(shù)據(jù)庫、調(diào)外部服務、做復雜計算這些操作如果直接放在從線程的處理器里仍然會阻塞那個事件循環(huán)拖累它名下幾百個連接。所以主從Reactor再演進一檔事件循環(huán)只做IO讀取、編解碼和數(shù)據(jù)分發(fā)得到完整業(yè)務請求后把任務丟給一個專門的后置業(yè)務線程池去執(zhí)行。業(yè)務線程池的處理結果通過異步回調(diào)方式送回事件循環(huán)再走寫事件把響應發(fā)出去。這樣一來事件循環(huán)線程永遠不會被慢業(yè)務阻塞而業(yè)務線程池只要能扛得住并發(fā)就可以用可配置的線程數(shù)量從容處理各種耗時操作。這一檔的代價是模型復雜度明顯上升跨線程投遞任務要處理并發(fā)、回調(diào)要保證線程安全、業(yè)務線程池要設計合理的隊列長度和拒絕策略。所以在小規(guī)模項目里不要一上來就上這套先分清瓶頸到底在哪再決定要不要加復雜度。下面用一個表格把三種形態(tài)的關鍵點擺在臺面上形態(tài)事件循環(huán)數(shù)量業(yè)務處理位置適合場景主要風險單線程Reactor1事件循環(huán)內(nèi)高吞吐、短任務、IO密集任何阻塞都會全局卡死主從Reactor1個主 N個從從事件循環(huán)內(nèi)大量連接、處理偏輕量慢業(yè)務仍會拖垮單事件循環(huán)主從Reactor 業(yè)務線程池1個主 N個從獨立業(yè)務線程池混合業(yè)務、含慢操作線程安全與復雜度顯著上升4. 手寫一個能跑的極簡ReactorLinux epoll路徑4.1 頂層骨架事件循環(huán)跑起來理論講再多都不如親手寫一個極簡Reactor來得直觀。這里我用類C的偽代碼風格展示核心結構主要為了體現(xiàn)出Reactor模式的骨架方便你遷移到任何語言。先看頂層事件循環(huán)。它的工作就是創(chuàng)建epoll實例往里面注冊事件源然后無限循環(huán)地調(diào)用epoll_wait拿到就緒事件后分發(fā)。// 偽代碼極簡Reactor事件循環(huán) EventLoop* loop event_loop_new(); // 注冊事件回調(diào)比如一個可讀事件對應一個handler loop-register_handler(socket_fd, EVENT_READ, on_read, context); while (loop-running) { // 阻塞等待事件就緒超時時間自行設定 struct epoll_event events[1024]; int n epoll_wait(loop-epoll_fd, events, 1024, -1); for (int i 0; i n; i) { EventHandler* h (EventHandler*)events[i].data.ptr; // 這一步就是“分發(fā)” h-handle_event(events[i].events, h-context); } }這段代碼看起來短卻包含了Reactor最常見的三個動作等待、分發(fā)、回調(diào)。實際工程里會在register_handler時把fd設置成非阻塞并把它和對應的handler綁定在一起放到一個數(shù)據(jù)結構里方便分發(fā)時直接找到處理器。4.2 事件處理器接口讓代碼可插拔事件循環(huán)不該知道業(yè)務細節(jié)所以需要定義統(tǒng)一的事件處理器接口。無論是監(jiān)聽新連接、讀取數(shù)據(jù)、寫出數(shù)據(jù)都是實現(xiàn)同一個接口// 事件處理器抽象接口 typedef struct EventHandler { void (*handle_event)(uint32_t events, void* context); void* context; // 保存socket、協(xié)議狀態(tài)等數(shù)據(jù) } EventHandler;新連接接入的邏輯在Reactor里通常叫Acceptor它本質(zhì)上是監(jiān)聽socket的一個讀事件處理器當listen socket可讀時說明有新連接來敲門于是調(diào)用accept把連接收下再給新連接創(chuàng)建對應的讀寫處理器并注冊到事件循環(huán)里。// 偽代碼Acceptor只負責收新連接 void accept_handler(uint32_t events, void* context) { Acceptor* acc (Acceptor*)context; int client_fd accept(acc-listen_fd, NULL, NULL); if (client_fd 0) { set_nonblocking(client_fd); // 關鍵為新連接注冊讀事件處理器 EventHandler* h create_read_handler(client_fd); acc-loop-register_handler(client_fd, EVENT_READ | EVENT_WRITE, h, h); } }這段代碼里最容易被忽略的是set_nonblocking。Reactor模式下所有IO都必須是非阻塞因為事件循環(huán)只負責通知你“可讀了”如果你的read操作因為數(shù)據(jù)沒到齊而阻塞那事件循環(huán)就卡死了。這也是工程上一個非常典型的隱患事件循環(huán)里的fd忘記設置非阻塞低峰期一切正常高峰期一壓測就集體掛起。4.3 從單線程到多線程快速演進思路極簡版單線程Reactor寫出來之后升級成多線程Reactor的思路其實非常順開多個事件循環(huán)線程每個線程獨立跑一個epoll實例主線程的Acceptor收到新連接后按某種負載均衡策略比如輪詢、按連接數(shù)最少把連接均勻分到各個事件循環(huán)線程去注冊。這樣每個事件循環(huán)只處理自己名下的一部分連接彼此之間沒有共享狀態(tài)也不需要加鎖。我在實際項目里用過一個更省事的分配方法不搞復雜負載均衡直接用原子計數(shù)器做round-robin每一萬個連接跑下來分布非常均勻代碼也就十幾行。復雜的調(diào)度策略在連接數(shù)分配這個場景下性價比很低真出現(xiàn)某個事件循環(huán)負載偏高時通常是因為業(yè)務分配不均而不是連接分配不勻。如果你想在這一版基礎上繼續(xù)充分壓榨CPU就把業(yè)務處理從事件循環(huán)里剝離加一個業(yè)務線程池。事件循環(huán)讀到完整請求后封裝成任務投遞給線程池線程池處理完成后通過內(nèi)部隊列把結果投回事件循環(huán)由它觸發(fā)寫事件向外發(fā)數(shù)據(jù)。這個結構就是目前主流網(wǎng)絡框架的最終形態(tài)理解之后再看任何開源框架你都不會迷路。5. 實操中反復踩過的坑5.1 回調(diào)里做了阻塞操作事件循環(huán)直接卡死這是Reactor模式殺傷力最大的一個坑幾乎每個寫過事件驅(qū)動服務的人都中過招。某次我接手一個線上服務現(xiàn)象是每天下午高峰時段會莫名出現(xiàn)幾秒鐘的全局限流排查了很久最后發(fā)現(xiàn)是某個接口寫了個同步的數(shù)據(jù)庫查詢直接放在事件處理器里。高峰時數(shù)據(jù)庫稍微慢了一下一個事件循環(huán)被卡住它手底下幾千條連接全部跟著延遲。排查方法很簡單在事件循環(huán)里給業(yè)務處理加上日志記錄每次處理的耗時如果出現(xiàn)毫秒級的耗時波動逐層往下找?；蛘咧苯釉谑录h(huán)里臨時引入一個監(jiān)控計數(shù)器每次循環(huán)記錄耗時分布。一旦發(fā)現(xiàn)某個處理器的耗時明顯偏高立刻就能鎖定問題。5.2 同一個連接上的讀寫事件互相餓死事件循環(huán)里一個fd可以同時監(jiān)聽讀事件和寫事件。如果寫事件處理器里做了大數(shù)據(jù)量發(fā)送恰巧發(fā)送緩沖區(qū)一直不滿那么寫事件會反復觸發(fā)占滿整個事件循環(huán)的處理時間導致同fd的讀事件遲遲得不到處理。這種問題在壓測大包流量時非常常見。常規(guī)解法是分級處理寫事件一旦觸發(fā)把待發(fā)數(shù)據(jù)盡量一次性寫完如果沒寫完也不要一條路寫到黑而是控制單次發(fā)送的數(shù)據(jù)量或者把寫事件從監(jiān)聽列表里暫時摘除等下一輪再注冊。核心原則是每個事件的處理時間應當被控制在很短的范圍內(nèi)你永遠不知道同一個循環(huán)里其他幾百上千個事件在等著你。5.3 連接分發(fā)時的驚群問題在多線程Reactor里如果主線程accept新連接后立即把連接注冊到某個事件循環(huán)看起來沒什么問題。但如果多個事件循環(huán)線程同時都監(jiān)聽同一個listen socket甚至每個線程都調(diào)用epoll_wait等待同一個listen fd那就可能出現(xiàn)“驚群”一個新連接進來內(nèi)核喚醒所有等待的線程但只有一個線程能成功accept其余線程白白空轉一圈。這個坑我剛接觸多Reactor時踩得很深后來特意研究了一下解決方案不外乎兩種要么讓listen fd只由一個主Reactor獨占accept之后再分發(fā)給其他Reactor要么使用內(nèi)核提供的負載均衡機制來避免驚群。對于絕大多數(shù)應用第一種方案已經(jīng)足夠為了那點accept性能去引入復雜的內(nèi)核特性得不償失。5.4 線程安全共享狀態(tài)比想象中更容易臟多線程Reactor最讓開發(fā)者頭疼的就是線程安全。事件循環(huán)線程之間通常不共享連接但業(yè)務層數(shù)據(jù)是共享的比如在線用戶表、房間列表、全局計數(shù)器。如果你在多個事件循環(huán)線程中直接修改這些共享狀態(tài)就會出現(xiàn)詭異的偶發(fā)問題好好的session突然不見了、用戶狀態(tài)偶爾對不上。經(jīng)驗做法是能按連接拆分的數(shù)據(jù)就盡量按連接拆分事件循環(huán)內(nèi)部只保存連接自己的狀態(tài)任何跨連接的數(shù)據(jù)操作都走統(tǒng)一的服務層接口并在該接口內(nèi)部完成加鎖。不要指望“這段代碼不會同時執(zhí)行”在不知被多少事件循環(huán)線程同時跑著的代碼里這句話永遠是錯的。5.5 背壓問題寫不出去怎么辦當服務端處理速度跟不上客戶端發(fā)送速度時你很快會遇到一個棘手的問題數(shù)據(jù)讀進來業(yè)務處理不過來了往終端或下游寫的時候發(fā)送緩沖區(qū)被填滿再繼續(xù)寫就會阻塞。Reactor模式下你沒法阻塞等待因為這會卡死事件循環(huán)。這時候必須建立背壓機制。常見的做法是為每個連接維護一個發(fā)送隊列數(shù)據(jù)量超過閾值時丟棄或拒絕新請求必要時直接斷掉超限連接。千萬不要無腦擴大發(fā)送緩沖區(qū)內(nèi)存是有限的一個連接撐爆內(nèi)存往往就是從“隊列無限增長”開始的。我在壓測時曾經(jīng)見過因為發(fā)送隊列沒有上限單連接堆積幾GB數(shù)據(jù)把服務打OOM的慘案。下面把這些問題整理成一張速查表方便你排查時對照現(xiàn)象根因快速處理方向所有連接周期性卡頓事件循環(huán)里出現(xiàn)阻塞操作定位慢處理器移出事件循環(huán)單連接性能差讀寫事件互相搶時間片限制單次處理量摘除事件監(jiān)聽多個事件循環(huán)同時空轉共有fd觸發(fā)驚群獨立listen線程accept后分發(fā)偶發(fā)數(shù)據(jù)錯亂共享狀態(tài)未加鎖隔離連接狀態(tài)統(tǒng)一服務層內(nèi)存持續(xù)上漲發(fā)送隊列無上限增加背壓控制異常斷連6. Reactor與Proactor的邊界選型時別搞混6.1 Reactor和Proactor到底差在哪Reactor和Proactor常常被放在一起比較但它們的差別其實非常本質(zhì)。Reactor是同步IO多路復用模式內(nèi)核通知你“可以讀了”你還要自己去調(diào)用read讀取數(shù)據(jù)讀取動作由用戶線程完成而Proactor是異步IO模式操作系統(tǒng)幫你把數(shù)據(jù)讀入指定的緩沖區(qū)讀完了再通知你“數(shù)據(jù)已經(jīng)放好了拿去用吧”。拿吃飯打比方Reactor模式是服務員告訴你“你的菜好啦請到取餐口取”你還要自己走過去端過來Proactor模式是服務員直接把菜端到你桌上你再掏筷子吃。兩者都是異步解耦但一個的“干活”動作還在用戶手里另一個的“干活”動作已經(jīng)由系統(tǒng)代勞了。實際工程里Proactor聽起來更省心但它要求操作系統(tǒng)提供良好的異步IO支持而且對“一次完整的讀寫”調(diào)度要求更高實現(xiàn)復雜度通常比Reactor高出一個數(shù)量級。這也是為什么大多數(shù)跨平臺網(wǎng)絡框架會優(yōu)先選擇Reactor只在特定平臺上充分利用系統(tǒng)異步IO接口。6.2 結合場景判斷該不該上Reactor選型時我給的建議是這樣的如果你的服務是短連接、事務型一次請求處理完就關閉并發(fā)量一般那完全不需要上Reactor直接用線程池阻塞模型即可代碼寫起來舒服得多。如果你的服務要面對長連接、海量連接、大部分連接長期掛機那Reactor是最穩(wěn)的底座單線程起步壓測后發(fā)現(xiàn)瓶頸再演進成主從結構逐步加復雜度。如果你的業(yè)務大量包含耗時操作比如查數(shù)據(jù)庫、調(diào)外部服務千萬別把所有邏輯都塞進事件循環(huán)要么上業(yè)務線程池要么干脆換異步等待模型。讓事件循環(huán)保持“輕載”是Reactor模式能長期穩(wěn)定運轉的核心原則。選型沒有絕對的正確答案核心是看你的瓶頸是連接數(shù)、吞吐量還是單請求耗時。把瓶頸想清楚了選型就水到渠成。結尾用了這么多年Reactor模式我自己最深的體會是它的門檻不在于理解那張經(jīng)典架構圖而在于你能不能守住“事件循環(huán)里不做重活”這條底線。架構圖畫起來誰都會真正難的是每時每刻都在提醒自己所有阻塞都必須從事件循環(huán)里剝離出去。另一個想說的小技巧如果你想快速驗證自己對Reactor的理解不要只讀框架源碼試著用你熟悉的語言照著上面的骨架寫一個能支撐幾百并發(fā)的最小實現(xiàn)。不用支持太多功能只要能完整走一遍accept、read、write事件分布鏈路你對這個模式的感受就會完全不同。寫壞了也沒關系踩過那幾個坑的人才是真正能把它用好的人。