小林，來了。
這次就來圖解 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 ，來看看非阻塞 I/O，非阻塞的 read 請求在資料未準備好的情況下立即返回，可以繼續往下執行，此時應用程式不斷輪詢核心，直到資料準備好，核心將資料拷貝到應用程式緩衝區，read 呼叫才可以獲取到結果。過程如下圖：
非阻塞 I/O
注意，這裡最後一次 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 效能更好，因為非同步 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
https://www.cnblogs.com/crazymakercircle/p/9833847.html
作者簡介：大家好，我是小林，一個專為大家圖解的工具人，微信搜尋「小林coding」，關注專注於圖解計算機基礎的我，寫了很多原創的圖解系列文章，如圖解網路、圖解系統、圖解資料庫等等，這麼賣力的圖解，當然是希望大家能學起來不會枯燥，小林期待你的關注，和我一起熱氣騰騰的成長。