摘要：無論是 Reactor，還是 Proactor，都是一種基於「事件分發」的網絡編程模式，區別在於 Reactor 模式是基於「待完成」的 I/O 事件，而 Proactor 模式則是基於「已完成」的 I/O 事件。
本文分享自華爲雲社區《高性能網絡框架：Reactor和 Proactor》，原文作者：小林 coding。
這次就來圖解 Reactor 和 Proactor 這兩個高性能網絡模式。
別小看這兩個東西，特別是 Reactor 模式，市面上常見的開源軟件很多都採用了這個方案，比如 Redis、Nginx、Netty 等等，所以學好這個模式設計的思想，不僅有助於我們理解很多開源軟件，而且也能在面試時吹逼。
發車！
演進
如果要讓服務器服務多個客戶端，那麼最直接的方式就是爲每一條連接創建線程。
其實創建進程也是可以的，原理是一樣的，進程和線程的區別在於線程比較輕量級些，線程的創建和線程間切換的成本要小些，爲了描述簡述，後面都以線程爲例。
處理完業務邏輯後，隨着連接關閉後線程也同樣要銷燬了，但是這樣不停地創建和銷燬線程，不僅會帶來性能開銷，也會造成浪費資源，而且如果要連接幾萬條連接，創建幾萬個線程去應對也是不現實的。
要這麼解決這個問題呢？我們可以使用「資源複用」的方式。
也就是不用再爲每個連接創建線程，而是創建一個「線程池」，將連接分配給線程，然後一個線程可以處理多個連接的業務。
不過，這樣又引來一個新的問題，線程怎樣才能高效地處理多個連接的業務？
當一個連接對應一個線程時，線程一般採用「read -> 業務處理 -> send」的處理流程，如果當前連接沒有數據可讀，那麼線程會阻塞在 read 操作上（ socket 默認情況是阻塞 I/O），不過這種阻塞方式並不影響其他線程。
但是引入了線程池，那麼一個線程要處理多個連接的業務，線程在處理某個連接的 read 操作時，如果遇到沒有數據可讀，就會發生阻塞，那麼線程就沒辦法繼續處理其他連接的業務。
要解決這一個問題，最簡單的方式就是將 socket 改成非阻塞，然後線程不斷地輪詢調用 read 操作來判斷是否有數據，這種方式雖然該能夠解決阻塞的問題，但是解決的方式比較粗暴，因爲輪詢是要消耗 CPU 的，而且隨着一個 線程處理的連接越多，輪詢的效率就會越低。
上面的問題在於，線程並不知道當前連接是否有數據可讀，從而需要每次通過 read 去試探。
那有沒有辦法在只有當連接上有數據的時候，線程纔去發起讀請求呢？答案是有的，實現這一技術的就是 I/O 多路複用。
I/O 多路複用技術會用一個系統調用函數來監聽我們所有關心的連接，也就說可以在一個監控線程裏面監控很多的連接。
我們熟悉的 select/poll/epoll 就是內核提供給用戶態的多路複用系統調用，線程可以通過一個系統調用函數從內核中獲取多個事件。
PS：如果想知道 select/poll/epoll 的區別，可以看看小林之前寫的這篇文章：這次答應我，一舉拿下 I/O 多路複用！
select/poll/epoll 是如何獲取網絡事件的呢？
在獲取事件時，先把我們要關心的連接傳給內核，再由內核檢測：
- 如果沒有事件發生，線程只需阻塞在這個系統調用，而無需像前面的線程池方案那樣輪訓調用 read 操作來判斷是否有數據。
- 如果有事件發生，內核會返回產生了事件的連接，線程就會從阻塞狀態返回，然後在用戶態中再處理這些連接對應的業務即可。
當下開源軟件能做到網絡高性能的原因就是 I/O 多路複用嗎？
是的，基本是基於 I/O 多路複用，用過 I/O 多路複用接口寫網絡程序的同學，肯定知道是面向過程的方式寫代碼的，這樣的開發的效率不高。
於是，大佬們基於面向對象的思想，對 I/O 多路複用作了一層封裝，讓使用者不用考慮底層網絡 API 的細節，只需要關注應用代碼的編寫。
大佬們還爲這種模式取了個讓人第一時間難以理解的名字：Reactor 模式。
Reactor 翻譯過來的意思是「反應堆」，可能大家會聯想到物理學裏的核反應堆，實際上並不是的這個意思。
這裏的反應指的是「對事件反應」，也就是來了一個事件，Reactor 就有相對應的反應/響應。
事實上，Reactor 模式也叫 Dispatcher 模式，我覺得這個名字更貼合該模式的含義，即 I/O 多路複用監聽事件，收到事件後，根據事件類型分配（Dispatch）給某個進程 / 線程。
Reactor 模式主要由 Reactor 和處理資源池這兩個核心部分組成，它倆負責的事情如下：
- Reactor 負責監聽和分發事件，事件類型包含連接事件、讀寫事件；
- 處理資源池負責處理事件，如 read -> 業務邏輯 -> send；
Reactor 模式是靈活多變的，可以應對不同的業務場景，靈活在於：
- Reactor 的數量可以只有一個，也可以有多個；
- 處理資源池可以是單個進程 / 線程，也可以是多個進程 /線程；
將上面的兩個因素排列組設一下，理論上就可以有 4 種方案選擇：
- 單 Reactor 單進程 / 線程；
- 單 Reactor 多進程 / 線程；
- 多 Reactor 單進程 / 線程；
- 多 Reactor 多進程 / 線程；
其中，「多 Reactor 單進程 / 線程」實現方案相比「單 Reactor 單進程 / 線程」方案，不僅複雜而且也沒有性能優勢，因此實際中並沒有應用。
剩下的 3 個方案都是比較經典的，且都有應用在實際的項目中：
- 單 Reactor 單進程 / 線程；
- 單 Reactor 多線程 / 進程；
- 多 Reactor 多進程 / 線程；
方案具體使用進程還是線程，要看使用的編程語言以及平臺有關：
- Java 語言一般使用線程，比如 Netty;
- C 語言使用進程和線程都可以，例如 Nginx 使用的是進程，Memcache 使用的是線程。
接下來，分別介紹這三個經典的 Reactor 方案。
Reactor
單 Reactor 單進程 / 線程
一般來說，C 語言實現的是「單 Reactor 單進程」的方案，因爲 C 語編寫完的程序，運行後就是一個獨立的進程，不需要在進程中再創建線程。
而 Java 語言實現的是「單 Reactor 單線程」的方案，因爲 Java 程序是跑在 Java 虛擬機這個進程上面的，虛擬機中有很多線程，我們寫的 Java 程序只是其中的一個線程而已。
我們來看看「單 Reactor 單進程」的方案示意圖：
可以看到進程裏有 Reactor、Acceptor、Handler 這三個對象：
- Reactor 對象的作用是監聽和分發事件；
- Acceptor 對象的作用是獲取連接；
- Handler 對象的作用是處理業務；
對象裏的 select、accept、read、send 是系統調用函數，dispatch 和 「業務處理」是需要完成的操作，其中 dispatch 是分發事件操作。
接下來，介紹下「單 Reactor 單進程」這個方案：
- Reactor 對象通過 select （IO 多路複用接口） 監聽事件，收到事件後通過 dispatch 進行分發，具體分發給 Acceptor 對象還是 Handler 對象，還要看收到的事件類型；
- 如果是連接建立的事件，則交由 Acceptor 對象進行處理，Acceptor 對象會通過 accept 方法 獲取連接，並創建一個 Handler 對象來處理後續的響應事件；
- 如果不是連接建立事件， 則交由當前連接對應的 Handler 對象來進行響應；
- Handler 對象通過 read -> 業務處理 -> send 的流程來完成完整的業務流程。
單 Reactor 單進程的方案因爲全部工作都在同一個進程內完成，所以實現起來比較簡單，不需要考慮進程間通信，也不用擔心多進程競爭。
但是，這種方案存在 2 個缺點：
- 第一個缺點，因爲只有一個進程，無法充分利用 多核 CPU 的性能；
- 第二個缺點，Handler 對象在業務處理時，整個進程是無法處理其他連接的事件的，如果業務處理耗時比較長，那麼就造成響應的延遲；
所以，單 Reactor 單進程的方案不適用計算機密集型的場景，只適用於業務處理非常快速的場景。
Redis 是由 C 語言實現的，它採用的正是「單 Reactor 單進程」的方案，因爲 Redis 業務處理主要是在內存中完成，操作的速度是很快的，性能瓶頸不在 CPU 上，所以 Redis 對於命令的處理是單進程的方案。
單 Reactor 多線程 / 多進程
如果要克服「單 Reactor 單線程 / 進程」方案的缺點，那麼就需要引入多線程 / 多進程，這樣就產生了單 Reactor 多線程/ 多進程的方案。
聞其名不如看其圖，先來看看「單 Reactor 多線程」方案的示意圖如下：
詳細說一下這個方案：
- Reactor 對象通過 select （IO 多路複用接口） 監聽事件，收到事件後通過 dispatch 進行分發，具體分發給 Acceptor 對象還是 Handler 對象，還要看收到的事件類型；
- 如果是連接建立的事件，則交由 Acceptor 對象進行處理，Acceptor 對象會通過 accept 方法 獲取連接，並創建一個 Handler 對象來處理後續的響應事件；
- 如果不是連接建立事件， 則交由當前連接對應的 Handler 對象來進行響應；
上面的三個步驟和單 Reactor 單線程方案是一樣的，接下來的步驟就開始不一樣了：
- Handler 對象不再負責業務處理，只負責數據的接收和發送，Handler 對象通過 read 讀取到數據後，會將數據發給子線程裏的 Processor 對象進行業務處理；
- 子線程裏的 Processor 對象就進行業務處理，處理完後，將結果發給主線程中的 Handler 對象，接着由 Handler 通過 send 方法將響應結果發送給 client；
單 Reator 多線程的方案優勢在於能夠充分利用多核 CPU 的能，那既然引入多線程，那麼自然就帶來了多線程競爭資源的問題。
例如，子線程完成業務處理後，要把結果傳遞給主線程的 Reactor 進行發送，這裏涉及共享數據的競爭。
要避免多線程由於競爭共享資源而導致數據錯亂的問題，就需要在操作共享資源前加上互斥鎖，以保證任意時間裏只有一個線程在操作共享資源，待該線程操作完釋放互斥鎖後，其他線程纔有機會操作共享數據。
聊完單 Reactor 多線程的方案，接着來看看單 Reactor 多進程的方案。
事實上，單 Reactor 多進程相比單 Reactor 多線程實現起來很麻煩，主要因爲要考慮子進程 <-> 父進程的雙向通信，並且父進程還得知道子進程要將數據發送給哪個客戶端。
而多線程間可以共享數據，雖然要額外考慮併發問題，但是這遠比進程間通信的複雜度低得多，因此實際應用中也看不到單 Reactor 多進程的模式。
另外，「單 Reactor」的模式還有個問題，因爲一個 Reactor 對象承擔所有事件的監聽和響應，而且只在主線程中運行，在面對瞬間高併發的場景時，容易成爲性能的瓶頸的地方。
多 Reactor 多進程 / 線程
要解決「單 Reactor」的問題，就是將「單 Reactor」實現成「多 Reactor」，這樣就產生了第 多 Reactor 多進程 / 線程的方案。
老規矩，聞其名不如看其圖。多 Reactor 多進程 / 線程方案的示意圖如下（以線程爲例）：
方案詳細說明如下：
- 主線程中的 MainReactor 對象通過 select 監控連接建立事件，收到事件後通過 Acceptor 對象中的 accept 獲取連接，將新的連接分配給某個子線程；
- 子線程中的 SubReactor 對象將 MainReactor 對象分配的連接加入 select 繼續進行監聽，並創建一個 Handler 用於處理連接的響應事件。
- 如果有新的事件發生時，SubReactor 對象會調用當前連接對應的 Handler 對象來進行響應。
- Handler 對象通過 read -> 業務處理 -> send 的流程來完成完整的業務流程。
多 Reactor 多線程的方案雖然看起來複雜的，但是實際實現時比單 Reactor 多線程的方案要簡單的多，原因如下：
- 主線程和子線程分工明確，主線程只負責接收新連接，子線程負責完成後續的業務處理。
- 主線程和子線程的交互很簡單，主線程只需要把新連接傳給子線程，子線程無須返回數據，直接就可以在子線程將處理結果發送給客戶端。
大名鼎鼎的兩個開源軟件 Netty 和 Memcache 都採用了「多 Reactor 多線程」的方案。
採用了「多 Reactor 多進程」方案的開源軟件是 Nginx，不過方案與標準的多 Reactor 多進程有些差異。
具體差異表現在主進程中僅僅用來初始化 socket，並沒有創建 mainReactor 來 accept 連接，而是由子進程的 Reactor 來 accept 連接，通過鎖來控制一次只有一個子進程進行 accept（防止出現驚羣現象），子進程 accept 新連接後就放到自己的 Reactor 進行處理，不會再分配給其他子進程。
Proactor
前面提到的 Reactor 是非阻塞同步網絡模式，而 Proactor 是異步網絡模式。
這裏先給大家複習下阻塞、非阻塞、同步、異步 I/O 的概念。
先來看看阻塞 I/O，當用戶程序執行 read，線程會被阻塞，一直等到內核數據準備好，並把數據從內核緩衝區拷貝到應用程序的緩衝區中，當拷貝過程完成，read 纔會返回。
注意，阻塞等待的是「內核數據準備好」和「數據從內核態拷貝到用戶態」這兩個過程。過程如下圖：
知道了阻塞 I/O ，來看看非阻塞 I/O，非阻塞的 read 請求在數據未準備好的情況下立即返回，可以繼續往下執行，此時應用程序不斷輪詢內核，直到數據準備好，內核將數據拷貝到應用程序緩衝區，read 調用纔可以獲取到結果。過程如下圖：
注意，這裏最後一次 read 調用，獲取數據的過程，是一個同步的過程，是需要等待的過程。這裏的同步指的是內核態的數據拷貝到用戶程序的緩存區這個過程。
舉個例子，如果 socket 設置了 O_NONBLOCK 標誌，那麼就表示使用的是非阻塞 I/O 的方式訪問，而不做任何設置的話，默認是阻塞 I/O。
因此，無論 read 和 send 是阻塞 I/O，還是非阻塞 I/O 都是同步調用。因爲在 read 調用時，內核將數據從內核空間拷貝到用戶空間的過程都是需要等待的，也就是說這個過程是同步的，如果內核實現的拷貝效率不高，read 調用就會在這個同步過程中等待比較長的時間。
而真正的異步 I/O 是「內核數據準備好」和「數據從內核態拷貝到用戶態」這兩個過程都不用等待。
當我們發起 aio_read（異步 I/O） 之後，就立即返回，內核自動將數據從內核空間拷貝到用戶空間，這個拷貝過程同樣是異步的，內核自動完成的，和前面的同步操作不一樣，應用程序並不需要主動發起拷貝動作。過程如下圖：
舉個你去飯堂喫飯的例子，你好比應用程序，飯堂好比操作系統。
阻塞 I/O 好比，你去飯堂喫飯，但是飯堂的菜還沒做好，然後你就一直在那裏等啊等，等了好長一段時間終於等到飯堂阿姨把菜端了出來（數據準備的過程），但是你還得繼續等阿姨把菜（內核空間）打到你的飯盒裏（用戶空間），經歷完這兩個過程，你纔可以離開。
非阻塞 I/O 好比，你去了飯堂，問阿姨菜做好了沒有，阿姨告訴你沒，你就離開了，過幾十分鐘，你又來飯堂問阿姨，阿姨說做好了，於是阿姨幫你把菜打到你的飯盒裏，這個過程你是得等待的。
異步 I/O 好比，你讓飯堂阿姨將菜做好並把菜打到飯盒裏後，把飯盒送到你面前，整個過程你都不需要任何等待。
很明顯，異步 I/O 比同步 I/O 性能更好，因爲異步 I/O 在「內核數據準備好」和「數據從內核空間拷貝到用戶空間」這兩個過程都不用等待。
Proactor 正是採用了異步 I/O 技術，所以被稱爲異步網絡模型。
現在我們再來理解 Reactor 和 Proactor 的區別，就比較清晰了。
- Reactor 是非阻塞同步網絡模式，感知的是就緒可讀寫事件。在每次感知到有事件發生（比如可讀就緒事件）後，就需要應用進程主動調用 read 方法來完成數據的讀取，也就是要應用進程主動將 socket 接收緩存中的數據讀到應用進程內存中，這個過程是同步的，讀取完數據後應用進程才能處理數據。
- Proactor 是異步網絡模式， 感知的是已完成的讀寫事件。在發起異步讀寫請求時，需要傳入數據緩衝區的地址（用來存放結果數據）等信息，這樣系統內核纔可以自動幫我們把數據的讀寫工作完成，這裏的讀寫工作全程由操作系統來做，並不需要像 Reactor 那樣還需要應用進程主動發起 read/write 來讀寫數據，操作系統完成讀寫工作後，就會通知應用進程直接處理數據。
因此，Reactor 可以理解爲「來了事件操作系統通知應用進程，讓應用進程來處理」，而 Proactor 可以理解爲「來了事件操作系統來處理，處理完再通知應用進程」。這裏的「事件」就是有新連接、有數據可讀、有數據可寫的這些 I/O 事件這裏的「處理」包含從驅動讀取到內核以及從內核讀取到用戶空間。
舉個實際生活中的例子，Reactor 模式就是快遞員在樓下，給你打電話告訴你快遞到你家小區了，你需要自己下樓來拿快遞。而在 Proactor 模式下，快遞員直接將快遞送到你家門口，然後通知你。
無論是 Reactor，還是 Proactor，都是一種基於「事件分發」的網絡編程模式，區別在於 Reactor 模式是基於「待完成」的 I/O 事件，而 Proactor 模式則是基於「已完成」的 I/O 事件。
接下來，一起看看 Proactor 模式的示意圖：
介紹一下 Proactor 模式的工作流程：
- Proactor Initiator 負責創建 Proactor 和 Handler 對象，並將 Proactor 和 Handler 都通過
- Asynchronous Operation Processor 註冊到內核；
- Asynchronous Operation Processor 負責處理註冊請求，並處理 I/O 操作；
- Asynchronous Operation Processor 完成 I/O 操作後通知 Proactor；
- Proactor 根據不同的事件類型回調不同的 Handler 進行業務處理；
- Handler 完成業務處理；
可惜的是，在 Linux 下的異步 I/O 是不完善的，aio 系列函數是由 POSIX 定義的異步操作接口，不是真正的操作系統級別支持的，而是在用戶空間模擬出來的異步，並且僅僅支持基於本地文件的 aio 異步操作，網絡編程中的 socket 是不支持的，這也使得基於 Linux 的高性能網絡程序都是使用 Reactor 方案。
而 Windows 裏實現了一套完整的支持 socket 的異步編程接口，這套接口就是 IOCP，是由操作系統級別實現的異步 I/O，真正意義上異步 I/O，因此在 Windows 裏實現高性能網絡程序可以使用效率更高的 Proactor 方案。
總結
常見的 Reactor 實現方案有三種。
第一種方案單 Reactor 單進程 / 線程，不用考慮進程間通信以及數據同步的問題，因此實現起來比較簡單，這種方案的缺陷在於無法充分利用多核 CPU，而且處理業務邏輯的時間不能太長，否則會延遲響應，所以不適用於計算機密集型的場景，適用於業務處理快速的場景，比如 Redis 採用的是單 Reactor 單進程的方案。
第二種方案單 Reactor 多線程，通過多線程的方式解決了方案一的缺陷，但它離高併發還差一點距離，差在只有一個 Reactor 對象來承擔所有事件的監聽和響應，而且只在主線程中運行，在面對瞬間高併發的場景時，容易成爲性能的瓶頸的地方。
第三種方案多 Reactor 多進程 / 線程，通過多個 Reactor 來解決了方案二的缺陷，主 Reactor 只負責監聽事件，響應事件的工作交給了從 Reactor，Netty 和 Memcache 都採用了「多 Reactor 多線程」的方案，Nginx 則採用了類似於 「多 Reactor 多進程」的方案。
Reactor 可以理解爲「來了事件操作系統通知應用進程，讓應用進程來處理」，而 Proactor 可以理解爲「來了事件操作系統來處理，處理完再通知應用進程」。
因此，真正的大殺器還是 Proactor，它是採用異步 I/O 實現的異步網絡模型，感知的是已完成的讀寫事件，而不需要像 Reactor 感知到事件後，還需要調用 read 來從內核中獲取數據。
不過，無論是 Reactor，還是 Proactor，都是一種基於「事件分發」的網絡編程模式，區別在於 Reactor 模式是基於「待完成」的 I/O 事件，而 Proactor 模式則是基於「已完成」的 I/O 事件。
參考資料
https://cloud.tencent.com/developer/article/1373468
https://blog.csdn.net/qq_27788177/article/details/98108466
https://time.geekbang.org/column/article/8805