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