PPC 和 TPC 模式，它們的優(yōu)點(diǎn)是實(shí)現(xiàn)簡單诊赊，缺點(diǎn)是都無法支撐高并發(fā)的場景厚满。
Reactor
PPC 模式最主要的問題就是每個(gè)連接都要?jiǎng)?chuàng)建進(jìn)程（為了描述簡潔，這里只以 PPC 和進(jìn)程為例碧磅，實(shí)際上換成 TPC 和線程碘箍，原理是一樣的），連接結(jié)束后進(jìn)程就銷毀了鲸郊，這樣做其實(shí)是很大的浪費(fèi)丰榴。為了解決這個(gè)問題，一個(gè)自然而然的想法就是資源復(fù)用秆撮，即不再單獨(dú)為每個(gè)連接創(chuàng)建進(jìn)程四濒，而是創(chuàng)建一個(gè)進(jìn)程池，將連接分配給進(jìn)程职辨，一個(gè)進(jìn)程可以處理多個(gè)連接的業(yè)務(wù)盗蟆。
引入資源池的處理方式后，會(huì)引出一個(gè)新的問題：進(jìn)程如何才能高效地處理多個(gè)連接的業(yè)務(wù)舒裤？當(dāng)一個(gè)連接一個(gè)進(jìn)程時(shí)喳资，進(jìn)程可以采用“read -> 業(yè)務(wù)處理 -> write”的處理流程，如果當(dāng)前連接沒有數(shù)據(jù)可以讀腾供，則進(jìn)程就阻塞在 read 操作上仆邓。這種阻塞的方式在一個(gè)連接一個(gè)進(jìn)程的場景下沒有問題，但如果一個(gè)進(jìn)程處理多個(gè)連接伴鳖，進(jìn)程阻塞在某個(gè)連接的 read 操作上节值，此時(shí)即使其他連接有數(shù)據(jù)可讀，進(jìn)程也無法去處理黎侈，很顯然這樣是無法做到高性能的。
解決這個(gè)問題的最簡單的方式是將 read 操作改為非阻塞闷游，然后進(jìn)程不斷地輪詢多個(gè)連接峻汉。這種方式能夠解決阻塞的問題，但解決的方式并不優(yōu)雅脐往。首先休吠，輪詢是要消耗 CPU 的；其次业簿，如果一個(gè)進(jìn)程處理幾千上萬的連接瘤礁，則輪詢的效率是很低的。
為了能夠更好地解決上述問題梅尤，很容易可以想到柜思，只有當(dāng)連接上有數(shù)據(jù)的時(shí)候進(jìn)程才去處理，這就是 I/O 多路復(fù)用技術(shù)的來源。
兩個(gè)關(guān)鍵實(shí)現(xiàn)點(diǎn)：
（1）當(dāng)多條連接共用一個(gè)阻塞對(duì)象后俯艰，進(jìn)程只需要在一個(gè)阻塞對(duì)象上等待权悟，而無須再輪詢所有連接，常見的實(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 的問題，而且“大神們”給它取了一個(gè)很牛的名字：Reactor喷斋，中文是“反應(yīng)堆”唁毒。聯(lián)想到“核反應(yīng)堆”，聽起來就很嚇人星爪，實(shí)際上這里的“反應(yīng)”不是聚變浆西、裂變反應(yīng)的意思，而是“事件反應(yīng)”的意思顽腾，可以通俗地理解為“來了一個(gè)事件我就有相應(yīng)的反應(yīng)”近零，這里的“我”就是 Reactor，具體的反應(yīng)就是我們寫的代碼抄肖，Reactor 會(huì)根據(jù)事件類型來調(diào)用相應(yīng)的代碼進(jìn)行處理久信。Reactor 模式也叫 Dispatcher 模式（在很多開源的系統(tǒng)里面會(huì)看到這個(gè)名稱的類，其實(shí)就是實(shí)現(xiàn) Reactor 模式的）漓摩，更加貼近模式本身的含義裙士，即 I/O 多路復(fù)用統(tǒng)一監(jiān)聽事件，收到事件后分配（Dispatch）給某個(gè)進(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ù)量可以變化：可以是一個(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ù)雜又沒有性能優(yōu)勢，因此“多 Reactor 單進(jìn)程”方案僅僅是一個(gè)理論上的方案十酣，實(shí)際沒有應(yīng)用涩拙。
最終 Reactor 模式有這三種典型的實(shí)現(xiàn)方案：
單 Reactor 單進(jìn)程 / 線程。
單 Reactor 多線程耸采。
多 Reactor 多進(jìn)程 / 線程兴泥。
以上方案具體選擇進(jìn)程還是線程，更多地是和編程語言及平臺(tái)相關(guān)虾宇。例如搓彻，Java 語言一般使用線程（例如，Netty）嘱朽，C 語言使用進(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ì)說明一下這個(gè)方案：
1）Reactor 對(duì)象通過 select 監(jiān)控連接事件方妖，收到事件后通過 dispatch 進(jìn)行分發(fā)狭魂。
2）如果是連接建立的事件，則由 Acceptor 處理党觅，Acceptor 通過 accept 接受連接雌澄，并創(chuàng)建一個(gè) Handler 來處理連接后續(xù)的各種事件。
如果不是連接建立事件仔役，則 Reactor 會(huì)調(diào)用連接對(duì)應(yīng)的 Handler（第 2 步中創(chuàng)建的 Handler）來進(jìn)行響應(yīng)掷伙。
3）Handler 會(huì)完成 read-> 業(yè)務(wù)處理 ->send 的完整業(yè)務(wù)流程是己。
單 Reactor 單進(jìn)程的模式優(yōu)點(diǎn)就是很簡單又兵，沒有進(jìn)程間通信，沒有進(jìn)程競爭，全部都在同一個(gè)進(jìn)程內(nèi)完成沛厨。但其缺點(diǎn)也是非常明顯宙地，具體表現(xiàn)有：
只有一個(gè)進(jìn)程，無法發(fā)揮多核 CPU 的性能逆皮；只能采取部署多個(gè)系統(tǒng)來利用多核 CPU宅粥，但這樣會(huì)帶來運(yùn)維復(fù)雜度，本來只要維護(hù)一個(gè)系統(tǒng)电谣，用這種方式需要在一臺(tái)機(jī)器上維護(hù)多套系統(tǒng)秽梅。
Handler 在處理某個(gè)連接上的業(yè)務(wù)時(shí)，整個(gè)進(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ī)是一個(gè)進(jìn)程，虛擬機(jī)中有很多線程整陌，業(yè)務(wù)線程只是其中的一個(gè)線程而已拗窃。
2. 單 Reactor 多線程
為了克服單 Reactor 單進(jìn)程 / 線程方案的缺點(diǎn)，引入多進(jìn)程 / 多線程是顯而易見的泌辫，這就產(chǎn)生了第 2 個(gè)方案：單 Reactor 多線程随夸。
單 Reactor 多線程方案示意圖是：
我來介紹一下這個(gè)方案：
主線程中，Reactor 對(duì)象通過 select 監(jiān)控連接事件震放，收到事件后通過 dispatch 進(jìn)行分發(fā)宾毒。
如果是連接建立的事件，則由 Acceptor 處理殿遂，Acceptor 通過 accept 接受連接诈铛，并創(chuàng)建一個(gè) Handler 來處理連接后續(xù)的各種事件。
如果不是連接建立事件墨礁，則 Reactor 會(huì)調(diào)用連接對(duì)應(yīng)的 Handler（第 2 步中創(chuàng)建的 Handler）來進(jìn)行響應(yīng)。
Handler 只負(fù)責(zé)響應(yīng)事件恩静，不進(jìn)行業(yè)務(wù)處理焕毫；Handler 通過 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)后通過 send 將響應(yīng)結(jié)果返回給 client乞旦。
單 Reator 多線程方案能夠充分利用多核多 CPU 的處理能力，但同時(shí)也存在下面的問題：
多線程數(shù)據(jù)共享和訪問比較復(fù)雜题山。例如杆查，子線程完成業(yè)務(wù)處理后，要把結(jié)果傳遞給主線程的 Reactor 進(jìn)行發(fā)送臀蛛，這里涉及共享數(shù)據(jù)的互斥和保護(hù)機(jī)制亲桦。以 Java 的 NIO 為例，Selector 是線程安全的浊仆，但是通過 Selector.selectKeys() 返回的鍵的集合是非線程安全的客峭，對(duì) selected keys 的處理必須單線程處理或者采取同步措施進(jìn)行保護(hù)。
Reactor 承擔(dān)所有事件的監(jiān)聽和響應(yīng)抡柿，只在主線程中運(yùn)行舔琅，瞬間高并發(fā)時(shí)會(huì)成為性能瓶頸。
你可能會(huì)發(fā)現(xiàn)洲劣，我只列出了“單 Reactor 多線程”方案备蚓，沒有列出“單 Reactor 多進(jìn)程”方案，這是什么原因呢囱稽？主要原因在于如果采用多進(jìn)程郊尝，子進(jìn)程完成業(yè)務(wù)處理后，將結(jié)果返回給父進(jìn)程战惊，并通知父進(jìn)程發(fā)送給哪個(gè) client流昏，這是很麻煩的事情。因?yàn)楦高M(jìn)程只是通過 Reactor 監(jiān)聽各個(gè)連接上的事件然后進(jìn)行分配吞获，子進(jìn)程與父進(jìn)程通信時(shí)并不是一個(gè)連接况凉。如果要將父進(jìn)程和子進(jìn)程之間的通信模擬為一個(gè)連接，并加入 Reactor 進(jìn)行監(jiān)聽各拷，則是比較復(fù)雜的刁绒。而采用多線程時(shí)，因?yàn)槎嗑€程是共享數(shù)據(jù)的烤黍，因此線程間通信是非常方便的知市。雖然要額外考慮線程間共享數(shù)據(jù)時(shí)的同步問題粮坞，但這個(gè)復(fù)雜度比進(jìn)程間通信的復(fù)雜度要低很多。
3. 多 Reactor 多進(jìn)程 / 線程
為了解決單 Reactor 多線程的問題初狰，最直觀的方法就是將單 Reactor 改為多 Reactor，這就產(chǎn)生了第 3 個(gè)方案：多 Reactor 多進(jìn)程 / 線程互例。
多 Reactor 多進(jìn)程 / 線程方案示意圖是（以進(jìn)程為例）：
方案詳細(xì)說明如下：
父進(jìn)程中 mainReactor 對(duì)象通過 select 監(jiān)控連接建立事件奢入，收到事件后通過 Acceptor 接收，將新的連接分配給某個(gè)子進(jìn)程媳叨。
子進(jìn)程的 subReactor 將 mainReactor 分配的連接加入連接隊(duì)列進(jìn)行監(jiān)聽腥光，并創(chuàng)建一個(gè) Handler 用于處理連接的各種事件。
當(dāng)有新的事件發(fā)生時(shí)糊秆，subReactor 會(huì)調(diào)用連接對(duì)應(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)時(shí)反而更加簡單捉片，主要原因是：
父進(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”連接，通過鎖來控制一次只有一個(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 可以理解為“來了事件我通知你量淌，你來處理”骗村，而 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é)處理注冊請(qǐng)求，并完成 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ò)編程時(shí)都是以 Reactor 模式為主癣猾。所以即使 Boost.Asio 號(hào)稱實(shí)現(xiàn)了 Proactor 模型敛劝，其實(shí)它在 Windows 下采用 IOCP，而在 Linux 下是用 Reactor 模式（采用 epoll）模擬出來的異步模型纷宇。
小結(jié)
針對(duì)“前浪微博”消息隊(duì)列架構(gòu)的案例夸盟，你覺得采用何種并發(fā)模式是比較合適的，為什么像捶？
評(píng)論1
Reactor與Proactor能不能這樣打個(gè)比方：
1上陕、假如我們?nèi)ワ埖挈c(diǎn)餐桩砰，飯店人很多，如果我們付了錢后站在收銀臺(tái)等著飯端上來我們才離開释簿，這就成了同步阻塞了亚隅。
2、如果我們付了錢后給你一個(gè)號(hào)就可以離開庶溶，飯好了老板會(huì)叫號(hào)煮纵，你過來取。這就是Reactor模型渐尿。
3、如果我們付了錢后給我一個(gè)號(hào)就可以坐到坐位上該干啥干啥矾瑰，飯好了老板會(huì)把飯端上來送給你砖茸。這就是Proactor模型了。
評(píng)論2
IO操作分兩個(gè)階段 1殴穴、等待數(shù)據(jù)準(zhǔn)備好(讀到內(nèi)核緩存) 2凉夯、將數(shù)據(jù)從內(nèi)核讀到用戶空間(進(jìn)程空間)?
一般來說1花費(fèi)的時(shí)間遠(yuǎn)遠(yuǎn)大于2。?
1上阻塞2上也阻塞的是同步阻塞IO?
1上非阻塞2阻塞的是同步非阻塞IO采幌，這講說的Reactor就是這種模型
1上非阻塞2上非阻塞是異步非阻塞IO劲够，這講說的Proactor模型就是這種模型
