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