Reactor
PPC 模式最主要的問題就是每個連接都要創建進程（為了描述簡潔，這里只以 PPC 和進程為例，實際上換成 TPC 和線程，原理是一樣的），連接結束后進程就銷毀了，這樣做其實是很大的浪費。為了解決這個問題，一個自然而然的想法就是資源復用，即不再單獨為每個連接創建進程，而是創建一個進程池，將連接分配給進程，一個進程可以處理多個連接的業務。
引入資源池的處理方式后，會引出一個新的問題：進程如何才能高效地處理多個連接的業務？當一個連接一個進程時，進程可以采用“read -> 業務處理 -> write”的處理流程，如果當前連接沒有數據可以讀，則進程就阻塞在 read 操作上。這種阻塞的方式在一個連接一個進程的場景下沒有問題，但如果一個進程處理多個連接，進程阻塞在某個連接的 read 操作上，此時即使其他連接有數據可讀，進程也無法去處理，很顯然這樣是無法做到高性能的。
解決這個問題的最簡單的方式是將 read 操作改為非阻塞，然后進程不斷地輪詢多個連接。這種方式能夠解決阻塞的問題，但解決的方式并不優雅。首先，輪詢是要消耗 CPU 的；其次，如果一個進程處理幾千上萬的連接，則輪詢的效率是很低的。
為了能夠更好地解決上述問題，很容易可以想到，只有當連接上有數據的時候進程才去處理，這就是 I/O 多路復用技術的來源。
I/O 多路復用技術歸納起來有兩個關鍵實現點：
當多條連接共用一個阻塞對象后，進程只需要在一個阻塞對象上等待，而無須再輪詢所有連接，常見的實現方式有 select、epoll、kqueue 等。
當某條連接有新的數據可以處理時，操作系統會通知進程，進程從阻塞狀態返回，開始進行業務處理。
I/O 多路復用結合線程池，完美地解決了 PPC 和 TPC 的問題，而且“大神們”給它取了一個很牛的名字：Reactor，中文是“反應堆”。聯想到“核反應堆”，聽起來就很嚇人，實際上這里的“反應”不是聚變、裂變反應的意思，而是“事件反應”的意思，可以通俗地理解為“來了一個事件我就有相應的反應”，這里的“我”就是 Reactor，具體的反應就是我們寫的代碼，Reactor 會根據事件類型來調用相應的代碼進行處理。Reactor 模式也叫 Dispatcher 模式（在很多開源的系統里面會看到這個名稱的類，其實就是實現 Reactor 模式的），更加貼近模式本身的含義，即 I/O 多路復用統一監聽事件，收到事件后分配（Dispatch）給某個進程。
Reactor 模式的核心組成部分包括 Reactor 和處理資源池（進程池或線程池），其中 Reactor 負責監聽和分配事件，處理資源池負責處理事件。初看 Reactor 的實現是比較簡單的，但實際上結合不同的業務場景，Reactor 模式的具體實現方案靈活多變，主要體現在：
Reactor 的數量可以變化：可以是一個 Reactor，也可以是多個 Reactor。
資源池的數量可以變化：以進程為例，可以是單個進程，也可以是多個進程（線程類似）。
將上面兩個因素排列組合一下，理論上可以有 4 種選擇，但由于“多 Reactor 單進程”實現方案相比“單 Reactor 單進程”方案，既復雜又沒有性能優勢，因此“多 Reactor 單進程”方案僅僅是一個理論上的方案，實際沒有應用。
最終 Reactor 模式有這三種典型的實現方案：
- 單 Reactor 單進程 / 線程。
- 單 Reactor 多線程。
- 多 Reactor 多進程 / 線程。
以上方案具體選擇進程還是線程，更多地是和編程語言及平臺相關。例如，Java 語言一般使用線程（例如，Netty），C 語言使用進程和線程都可以。例如，Nginx 使用進程，Memcache 使用線程。
- 單 Reactor 單進程 / 線程
單 Reactor 單進程 / 線程的方案示意圖如下（以進程為例）：
注意，select、accept、read、send 是標準的網絡編程 API，dispatch 和“業務處理”是需要完成的操作，其他方案示意圖類似。
詳細說明一下這個方案：
Reactor 對象通過 select 監控連接事件，收到事件后通過 dispatch 進行分發。
如果是連接建立的事件，則由 Acceptor 處理，Acceptor 通過 accept 接受連接，并創建一個 Handler 來處理連接后續的各種事件。
如果不是連接建立事件，則 Reactor 會調用連接對應的 Handler（第 2 步中創建的 Handler）來進行響應。
Handler 會完成 read-> 業務處理 ->send 的完整業務流程。
單 Reactor 單進程的模式優點就是很簡單，沒有進程間通信，沒有進程競爭，全部都在同一個進程內完成。但其缺點也是非常明顯，具體表現有：
只有一個進程，無法發揮多核 CPU 的性能；只能采取部署多個系統來利用多核 CPU，但這樣會帶來運維復雜度，本來只要維護一個系統，用這種方式需要在一臺機器上維護多套系統。
Handler 在處理某個連接上的業務時，整個進程無法處理其他連接的事件，很容易導致性能瓶頸。
因此，單 Reactor 單進程的方案在實踐中應用場景不多，只適用于業務處理非常快速的場景，目前比較著名的開源軟件中使用單 Reactor 單進程的是 Redis。
需要注意的是，C 語言編寫系統的一般使用單 Reactor 單進程，因為沒有必要在進程中再創建線程；而 Java 語言編寫的一般使用單 Reactor 單線程，因為 Java 虛擬機是一個進程，虛擬機中有很多線程，業務線程只是其中的一個線程而已。
- 單 Reactor 多線程
為了克服單 Reactor 單進程 / 線程方案的缺點，引入多進程 / 多線程是顯而易見的，這就產生了第 2 個方案：單 Reactor 多線程。
單 Reactor 多線程方案示意圖是：
主線程中，Reactor 對象通過 select 監控連接事件，收到事件后通過 dispatch 進行分發。
如果是連接建立的事件，則由 Acceptor 處理，Acceptor 通過 accept 接受連接，并創建一個 Handler 來處理連接后續的各種事件。
如果不是連接建立事件，則 Reactor 會調用連接對應的 Handler（第 2 步中創建的 Handler）來進行響應。
Handler 只負責響應事件，不進行業務處理；Handler 通過 read 讀取到數據后，會發給 Processor 進行業務處理。
Processor 會在獨立的子線程中完成真正的業務處理，然后將響應結果發給主進程的 Handler 處理；Handler 收到響應后通過 send 將響應結果返回給 client。
單 Reator 多線程方案能夠充分利用多核多 CPU 的處理能力，但同時也存在下面的問題：
多線程數據共享和訪問比較復雜。例如，子線程完成業務處理后，要把結果傳遞給主線程的 Reactor 進行發送，這里涉及共享數據的互斥和保護機制。以 Java 的 NIO 為例，Selector 是線程安全的，但是通過 Selector.selectKeys() 返回的鍵的集合是非線程安全的，對 selected keys 的處理必須單線程處理或者采取同步措施進行保護。
Reactor 承擔所有事件的監聽和響應，只在主線程中運行，瞬間高并發時會成為性能瓶頸。
你可能會發現，我只列出了“單 Reactor 多線程”方案，沒有列出“單 Reactor 多進程”方案，這是什么原因呢？主要原因在于如果采用多進程，子進程完成業務處理后，將結果返回給父進程，并通知父進程發送給哪個 client，這是很麻煩的事情。因為父進程只是通過 Reactor 監聽各個連接上的事件然后進行分配，子進程與父進程通信時并不是一個連接。如果要將父進程和子進程之間的通信模擬為一個連接，并加入 Reactor 進行監聽，則是比較復雜的。而采用多線程時，因為多線程是共享數據的，因此線程間通信是非常方便的。雖然要額外考慮線程間共享數據時的同步問題，但這個復雜度比進程間通信的復雜度要低很多。
- 多 Reactor 多進程 / 線程
為了解決單 Reactor 多線程的問題，最直觀的方法就是將單 Reactor 改為多 Reactor，這就產生了第 3 個方案：多 Reactor 多進程 / 線程。
多 Reactor 多進程 / 線程方案示意圖是（以進程為例）：
方案詳細說明如下：
父進程中 mainReactor 對象通過 select 監控連接建立事件，收到事件后通過 Acceptor 接收，將新的連接分配給某個子進程。
子進程的 subReactor 將 mainReactor 分配的連接加入連接隊列進行監聽，并創建一個 Handler 用于處理連接的各種事件。
當有新的事件發生時，subReactor 會調用連接對應的 Handler（即第 2 步中創建的 Handler）來進行響應。
Handler 完成 read→業務處理→send 的完整業務流程。
多 Reactor 多進程 / 線程的方案看起來比單 Reactor 多線程要復雜，但實際實現時反而更加簡單，主要原因是：
父進程和子進程的職責非常明確，父進程只負責接收新連接，子進程負責完成后續的業務處理。
父進程和子進程的交互很簡單，父進程只需要把新連接傳給子進程，子進程無須返回數據。
子進程之間是互相獨立的，無須同步共享之類的處理（這里僅限于網絡模型相關的 select、read、send 等無須同步共享，“業務處理”還是有可能需要同步共享的）。
目前著名的開源系統 Nginx 采用的是多 Reactor 多進程，采用多 Reactor 多線程的實現有 Memcache 和 Netty。
Nginx 采用的是多 Reactor 多進程的模式，但方案與標準的多 Reactor 多進程有差異。具體差異表現為主進程中僅僅創建了監聽端口，并沒有創建 mainReactor 來“accept”連接，而是由子進程的 Reactor 來“accept”連接，通過鎖來控制一次只有一個子進程進行“accept”，子進程“accept”新連接后就放到自己的 Reactor 進行處理，不會再分配給其他子進程，更多細節請查閱相關資料或閱讀 Nginx 源碼。
Proactor
Reactor 是非阻塞同步網絡模型，因為真正的 read 和 send 操作都需要用戶進程同步操作。這里的“同步”指用戶進程在執行 read 和 send 這類 I/O 操作的時候是同步的，如果把 I/O 操作改為異步就能夠進一步提升性能，這就是異步網絡模型 Proactor。
Proactor 中文翻譯為“前攝器”比較難理解，與其類似的單詞是 proactive，含義為“主動的”，因此我們照貓畫虎翻譯為“主動器”反而更好理解。Reactor 可以理解為“來了事件我通知你，你來處理”，而 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 完成業務處理，Handler 也可以注冊新的 Handler 到內核進程。
理論上 Proactor 比 Reactor 效率要高一些，異步 I/O 能夠充分利用 DMA 特性，讓 I/O 操作與計算重疊，但要實現真正的異步 I/O，操作系統需要做大量的工作。目前 Windows 下通過 IOCP 實現了真正的異步 I/O，而在 Linux 系統下的 AIO 并不完善，因此在 Linux 下實現高并發網絡編程時都是以 Reactor 模式為主。所以即使 Boost.Asio 號稱實現了 Proactor 模型，其實它在 Windows 下采用 IOCP，而在 Linux 下是用 Reactor 模式（采用 epoll）模擬出來的異步模型。
——學自咕泡學院
