兩種高效的事件處理模式

服務(wù)器程序通常需要處理三類(lèi)事件：I/O 事件、信號(hào)及定時(shí)事件。有兩種高效的事件處理模式：Reactor和 Proactor，同步 I/O 模型通常用于實(shí)現(xiàn)Reactor 模式，異步 I/O 模型通常用于實(shí)現(xiàn) Proactor 模式。

無(wú)論是 Reactor，還是 Proactor，都是一種基于「事件分發(fā)」的網(wǎng)絡(luò)編程模式，區(qū)別在于 Reactor 模式是基于「待完成」的 I/O 事件，而 Proactor 模式則是基于「已完成」的 I/O 事件

Reactor可以理解為：來(lái)了事件是由操作系統(tǒng)通知應(yīng)用程序，讓?xiě)?yīng)用程序來(lái)處理。又因?yàn)椤緝?nèi)核中的數(shù)據(jù)準(zhǔn)備階段和數(shù)據(jù)就緒并由內(nèi)核態(tài)切換到用戶(hù)態(tài)】這兩個(gè)過(guò)程對(duì)應(yīng)用層來(lái)說(shuō)是需要主動(dòng)調(diào)用read來(lái)等待的，所以Reactor一般都是用同步IO實(shí)現(xiàn)。

Proactor可以理解為：來(lái)了事件是由操作系統(tǒng)處理好了之后再通知應(yīng)用程序。又因?yàn)椤緝?nèi)核中會(huì)由異步線(xiàn)程把數(shù)據(jù)準(zhǔn)備好并且處理好了之后，直接通過(guò)信號(hào)中斷告訴應(yīng)用層】，對(duì)于應(yīng)用程序來(lái)說(shuō)，得到的是已經(jīng)完成讀寫(xiě)的事件，這個(gè)過(guò)程不需要等待。因此Proactor一般都是用異步IO實(shí)現(xiàn)的。

Linux基本上逐步實(shí)現(xiàn)了POSIX兼容，但并沒(méi)有參加正式的POSIX認(rèn)證。由于Linux下的異步IO不完善，aio_read,aio_write系列函數(shù)是由POSIX定義的異步操作接口，不是真正操作系統(tǒng)級(jí)別支持的，而是在用戶(hù)空間模擬出來(lái)的異步，并且僅支持本地文件的aio異步操作，網(wǎng)絡(luò)編程中的socket是不支持的。所以本文沒(méi)有講述異步IO實(shí)現(xiàn)Proactor模式，取而代之的是同步IO模擬實(shí)現(xiàn)Proactor模式。

①同步IO實(shí)現(xiàn)reactor模式：主線(xiàn)程只負(fù)責(zé)監(jiān)聽(tīng)lfd，accept成功之后把新創(chuàng)建的cfd交給子線(xiàn)程。子線(xiàn)程再通過(guò)IO多路復(fù)用去監(jiān)聽(tīng)cfd的讀寫(xiě)數(shù)據(jù)，并且處理客戶(hù)端業(yè)務(wù)。（主線(xiàn)程把已被觸發(fā)但是還未完成的事件分發(fā)給子線(xiàn)程）

·································································································

②同步IO模擬proactor模式：是主線(xiàn)程accpet監(jiān)聽(tīng)lfd，并且lfd讀事件觸發(fā)時(shí)，建立連接并創(chuàng)建cfd，并且通過(guò)epoll_ctl把cfd注冊(cè)到內(nèi)核的監(jiān)聽(tīng)樹(shù)中，等到該socket的讀事件就緒時(shí)，主線(xiàn)程進(jìn)行讀操作，把讀到的內(nèi)容交給子線(xiàn)程去進(jìn)行業(yè)務(wù)處理，然后子線(xiàn)程處理完業(yè)務(wù)之后把該socketfd又注冊(cè)為寫(xiě)時(shí)間就緒，并且把數(shù)據(jù)交回給主線(xiàn)程，由主線(xiàn)程寫(xiě)回給客戶(hù)端。

（主線(xiàn)程模擬真實(shí)Proactor模式中的異步線(xiàn)程，把已完成的事件分發(fā)給子線(xiàn)程）

下面的并發(fā)模型中，常用的是:

1??模型四（同步IO模擬proactor模式）

2??模型五線(xiàn)程池版本 （同步IO實(shí)現(xiàn)reactor模式）

在客戶(hù)端數(shù)量非常多的時(shí)候適合用模型五，但是在客戶(hù)端數(shù)量不多的時(shí)候使用模型四可能會(huì)效率更好，因?yàn)槟Ｐ退牡木€(xiàn)程數(shù)量更少，減少CPU切換線(xiàn)程的頻率。

為什么要用同步IO模擬proactor模式呢？

理論上 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)稱(chēng)實(shí)現(xiàn)了 Proactor 模型，其實(shí)它在 Windows 下采用 IOCP，而在 Linux 下是用 Reactor 模式（采用 epoll）模擬出來(lái)的異步模型

服務(wù)器開(kāi)發(fā)常見(jiàn)的并發(fā)模型

只要是做服務(wù)器開(kāi)發(fā)，那么常見(jiàn)的模型是通用的，C/C++/go等等都是通用的，因?yàn)檫@是一種設(shè)計(jì)思想。

其中模型四和模型五是實(shí)際開(kāi)發(fā)中主流的，而模型六過(guò)于理想化目前的硬件無(wú)法實(shí)現(xiàn)。

模型一：?jiǎn)尉€(xiàn)程accept（無(wú)IO復(fù)用）

模型分析：

• ①主線(xiàn)程執(zhí)行阻塞accept，每次客戶(hù)端connect請(qǐng)求連接過(guò)來(lái)，主線(xiàn)程中的accept響應(yīng)并建立連接
• ②創(chuàng)建連接成功之后，得到新的套接字文件描述符cfd（用于與客戶(hù)端通信），然后在主線(xiàn)程串行處理套接字讀寫(xiě)，并處理業(yè)務(wù)。
• ③在②的處理業(yè)務(wù)時(shí)，如果有新的客戶(hù)端發(fā)送請(qǐng)求連接，會(huì)被阻塞，服務(wù)器無(wú)響應(yīng)，直到當(dāng)前的cfd全部業(yè)務(wù)處理完畢，重新回到accept阻塞監(jiān)聽(tīng)狀態(tài)時(shí)，才會(huì)從請(qǐng)求隊(duì)列中選取第一個(gè)lfd進(jìn)行連接。

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• socket編程流程清晰且簡(jiǎn)單，適合學(xué)習(xí)使用，了解socket基本編程流程。

缺點(diǎn)：

• 該模型并非并發(fā)模型，是串行的服務(wù)器，同一時(shí)刻，監(jiān)聽(tīng)并響應(yīng)最大的網(wǎng)絡(luò)請(qǐng)求量為1。即并發(fā)量為1。
• 僅適合學(xué)習(xí)基本socket編程，不適合任何服務(wù)器Server構(gòu)建。

模型二：?jiǎn)尉€(xiàn)程accept + 多線(xiàn)程讀寫(xiě)業(yè)務(wù)（無(wú)IO復(fù)用）

模型分析：

• ①主線(xiàn)程執(zhí)行accept阻塞監(jiān)聽(tīng)，每當(dāng)有客戶(hù)端connect連接請(qǐng)求過(guò)來(lái)，主線(xiàn)程中的accept響應(yīng)并且與客戶(hù)端建立連接
• ②創(chuàng)建連接成功后得到新的cfd，然后再thread_create一個(gè)新的線(xiàn)程用來(lái)處理客戶(hù)端的讀寫(xiě)業(yè)務(wù)，并且主線(xiàn)程馬上回到accept阻塞監(jiān)聽(tīng)繼續(xù)等待新客戶(hù)端的連接請(qǐng)求
• ③這個(gè)新的線(xiàn)程通過(guò)套接字cfd與客戶(hù)端進(jìn)行通信讀寫(xiě)
• ④服務(wù)器在②處理業(yè)務(wù)中，如果有新客戶(hù)端發(fā)送申請(qǐng)連接過(guò)來(lái)，主線(xiàn)程accept依然會(huì)響應(yīng)并且簡(jiǎn)歷連接，重復(fù)②過(guò)程。

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• 基于模型一作了改進(jìn)，支持了并發(fā)
• 使用靈活，一個(gè)client對(duì)應(yīng)一個(gè)thread單獨(dú)處理，server處理業(yè)務(wù)的內(nèi)聚程度高（一個(gè)好的內(nèi)聚模塊應(yīng)當(dāng)恰好做一件事）?？蛻?hù)端無(wú)論如何寫(xiě)，服務(wù)端都會(huì)有一個(gè)線(xiàn)程做資源響應(yīng)。

缺點(diǎn)：

• 隨著客戶(hù)端的數(shù)量增多，需要開(kāi)辟的線(xiàn)程也增加，客戶(hù)端與服務(wù)端線(xiàn)程數(shù)量是1：1正比關(guān)系。因此對(duì)于高并發(fā)場(chǎng)景，線(xiàn)程數(shù)量收到硬件的瓶頸制約。線(xiàn)程過(guò)多也會(huì)增加CPU的切換成本，降低CPU的利用率。
• 對(duì)于長(zhǎng)連接，客戶(hù)端一旦沒(méi)有業(yè)務(wù)讀寫(xiě)操作，只要客戶(hù)端不關(guān)閉，服務(wù)端的對(duì)應(yīng)線(xiàn)程就必須要保持連接（心跳包、健康監(jiān)測(cè)等機(jī)制），占用連接資源和線(xiàn)程的開(kāi)銷(xiāo)
• 僅適合客戶(hù)端數(shù)量不大，并且是可控的場(chǎng)景來(lái)使用
• 僅適合學(xué)習(xí)基本的socket編程，不適合做并發(fā)服務(wù)器

模型三：?jiǎn)尉€(xiàn)程多路IO復(fù)用

模型分析：

• ①主線(xiàn)程main thread 創(chuàng)建 lfd之后，采用多路IO復(fù)用機(jī)制（如select和epoll）進(jìn)行IO狀態(tài)阻塞監(jiān)聽(tīng)。有client1客戶(hù)端 connect 請(qǐng)求， IO復(fù)用機(jī)制檢測(cè)到lfd觸發(fā)事件讀寫(xiě)，則進(jìn)行accept建立連接，并將新生成的cfd1加入到監(jiān)聽(tīng)I(yíng)O集合中。
• ②client1 再次進(jìn)行正常讀寫(xiě)業(yè)務(wù)請(qǐng)求，主線(xiàn)程的多路IO復(fù)用機(jī)制阻塞返回，主線(xiàn)程與client1進(jìn)行讀寫(xiě)通信業(yè)務(wù)。等到讀寫(xiě)業(yè)務(wù)結(jié)束后，會(huì)再次返回多路IO復(fù)用的地方進(jìn)行阻塞監(jiān)聽(tīng)。
• ③如果client1正在進(jìn)行讀寫(xiě)業(yè)務(wù)時(shí)，server依然在主線(xiàn)程執(zhí)行流程中繼續(xù)執(zhí)行，此時(shí)如果有新的客戶(hù)端申請(qǐng)連接請(qǐng)求，server將沒(méi)有辦法及時(shí)響應(yīng)（因?yàn)槭菃尉€(xiàn)程，server正在讀寫(xiě)），將會(huì)把這些還沒(méi)來(lái)得及響應(yīng)的請(qǐng)求加入阻塞隊(duì)列中。
• ④等到server處理完一個(gè)客戶(hù)端連接的讀寫(xiě)操作時(shí)，繼續(xù)回到多路IO復(fù)用機(jī)制處阻塞，其他的連接如果再發(fā)送連接請(qǐng)求過(guò)來(lái)的話(huà)，會(huì)繼續(xù)重復(fù)②③流程。

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• 單線(xiàn)程/單進(jìn)程解決了可以同時(shí)監(jiān)聽(tīng)多個(gè)客戶(hù)端讀寫(xiě)狀態(tài)的模型，不需要1：1與客戶(hù)端的線(xiàn)程數(shù)量關(guān)系。而是1：n；
• 多路IO復(fù)用阻塞，不需要一直輪詢(xún)，所以不會(huì)浪費(fèi)CPU資源，CPU利用效率較高。

缺點(diǎn)：

• 因?yàn)槭菃尉€(xiàn)程/單線(xiàn)程，雖然可以監(jiān)聽(tīng)多個(gè)客戶(hù)端的讀寫(xiě)狀態(tài)，但是在同一時(shí)間內(nèi)，只能處理一個(gè)客戶(hù)端的讀寫(xiě)操作，實(shí)際上讀寫(xiě)的業(yè)務(wù)并發(fā)為1；
• 多客戶(hù)端訪(fǎng)問(wèn)服務(wù)器，但是業(yè)務(wù)為串行執(zhí)行，大量請(qǐng)求會(huì)有排隊(duì)延遲現(xiàn)象。如圖中⑤所示，當(dāng)client3占據(jù)主線(xiàn)程流程時(shí)， client1和client2流程會(huì)卡在IO復(fù)用，等待下次監(jiān)聽(tīng)觸發(fā)事件。

是否滿(mǎn)足實(shí)際開(kāi)發(fā)？

可以！該模型編寫(xiě)代碼較簡(jiǎn)單，雖然有延遲現(xiàn)象，但是畢竟多路IO復(fù)用機(jī)制阻塞，不會(huì)占用CPU資源，如果并發(fā)請(qǐng)求量比較小，客戶(hù)端數(shù)量可數(shù)，允許信息有一點(diǎn)點(diǎn)延遲，可以使用該模型。

比如Redis就是采用該模型設(shè)計(jì)的，因?yàn)镽edis業(yè)務(wù)處理主要是在內(nèi)存中完成的，操作速度很快，性能瓶頸不在CPU上。

模型四：?jiǎn)尉€(xiàn)程多路IO復(fù)用 + 多線(xiàn)程業(yè)務(wù)工作池

模型分析：

前兩步跟模型三一致

• ①主線(xiàn)程main thread 創(chuàng)建 lfd之后，采用多路IO復(fù)用機(jī)制（如select和epoll）進(jìn)行IO狀態(tài)阻塞監(jiān)聽(tīng)。有client1客戶(hù)端 connect 請(qǐng)求， IO復(fù)用機(jī)制檢測(cè)到lfd觸發(fā)事件讀寫(xiě)，則進(jìn)行accept建立連接，并將新生成的cfd1加入到監(jiān)聽(tīng)I(yíng)O集合中。
• ②當(dāng)cfd1有可讀消息，觸發(fā)讀事件，并且進(jìn)行讀寫(xiě)消息。
• ③主線(xiàn)程按照固定的協(xié)議讀取消息，并且交給worker pool工作線(xiàn)程池，工作線(xiàn)程池在server啟動(dòng)之前就已經(jīng)開(kāi)啟固定數(shù)量的線(xiàn)程，里面的線(xiàn)程只處理消息業(yè)務(wù)，不進(jìn)行套接字讀寫(xiě)操作。
• ④工作池處理完業(yè)務(wù)，觸發(fā)cfd1寫(xiě)事件，將要回發(fā)客戶(hù)端的數(shù)據(jù)消息通過(guò)主線(xiàn)程寫(xiě)回給客戶(hù)端

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• 相比于模型三而言，設(shè)計(jì)了一個(gè)worker pool業(yè)務(wù)線(xiàn)程池，將業(yè)務(wù)處理部分從主線(xiàn)程抽離出來(lái)，為主線(xiàn)程分擔(dān)了業(yè)務(wù)處理的工作，減少了因?yàn)閱尉€(xiàn)程的串行執(zhí)行業(yè)務(wù)機(jī)制，多客戶(hù)端對(duì)server的大量請(qǐng)求造成排隊(duì)延遲的時(shí)間。就是說(shuō)主線(xiàn)程讀完數(shù)據(jù)之后馬上就丟給了線(xiàn)程池去處理，然后馬上回到多路IO復(fù)用的阻塞監(jiān)聽(tīng)狀態(tài)?？s短了其他客戶(hù)端的等待連接時(shí)間。
• 由于是單線(xiàn)程，實(shí)際上讀寫(xiě)的業(yè)務(wù)并發(fā)還是為1，但是業(yè)務(wù)流程的并發(fā)數(shù)為worker pool線(xiàn)程池里的線(xiàn)程數(shù)量，加快了業(yè)務(wù)處理并行效率。

缺點(diǎn)：

• 讀寫(xiě)依然是主線(xiàn)程單獨(dú)處理，最高的讀寫(xiě)并行通道依然是1，導(dǎo)致當(dāng)前服務(wù)器的并發(fā)性能依然沒(méi)有提升，只是響應(yīng)任務(wù)的速度快了。每個(gè)客戶(hù)端的排隊(duì)時(shí)間短了，但因?yàn)檫€是只有一個(gè)通道進(jìn)行讀寫(xiě)操作，因此總體的完成度跟模型3是差不多的。
• 雖然多個(gè)worker線(xiàn)程池處理業(yè)務(wù)，但是最后返回給客戶(hù)端依舊也需要排隊(duì)。因?yàn)槌隹谶€是只有read+write 這1個(gè)通道。因此業(yè)務(wù)是可以并行了，但是總體的效率是不變的。
• 模型三是客戶(hù)端向server發(fā)起請(qǐng)求時(shí)需要排隊(duì)，模型四是業(yè)務(wù)處理完之后回寫(xiě)客戶(hù)端需要排隊(duì)。

是否滿(mǎn)足實(shí)際開(kāi)發(fā)？

可以！模型三跟模型四的總體并發(fā)效率差不多，因?yàn)檫€是一個(gè)線(xiàn)程進(jìn)行讀寫(xiě)。但是對(duì)于客戶(hù)端的體驗(yàn)來(lái)說(shuō)，會(huì)覺(jué)得響應(yīng)速度變快，減少了在服務(wù)器的排隊(duì)時(shí)間。如果客戶(hù)端數(shù)量不多，并且各個(gè)客戶(hù)端的邏輯業(yè)務(wù)有并行需求的話(huà)適合用該模型。

模型五：?jiǎn)尉€(xiàn)程多路IO復(fù)用 + 多線(xiàn)程多路IO復(fù)用（線(xiàn)程池）實(shí)際中最常用

模型分析：

• ①server在啟動(dòng)監(jiān)聽(tīng)之前，需要?jiǎng)?chuàng)建固定數(shù)量N的線(xiàn)程，作為thread pool線(xiàn)程池。
• ②主線(xiàn)程創(chuàng)建lfd之后，采用多路IO復(fù)用機(jī)制（如select、epoll）進(jìn)行IO狀態(tài)阻塞監(jiān)聽(tīng)。有client1客戶(hù)端 connect請(qǐng)求，IO復(fù)用機(jī)制檢測(cè)到lfd觸發(fā)讀事件，則進(jìn)行accept建立連接，并且將新創(chuàng)建的cfd1分發(fā)給thread pool線(xiàn)程池中的某個(gè)線(xiàn)程監(jiān)聽(tīng)。
• ③thread pool中的每個(gè)thread都啟動(dòng)多路IO復(fù)用機(jī)制，用來(lái)監(jiān)聽(tīng)主線(xiàn)程建立成功并且分發(fā)下來(lái)的socket套接字（cfd）。
• ④如圖，thread1監(jiān)聽(tīng)cfd1、cfd2，thread2監(jiān)聽(tīng)cfd3，thread3監(jiān)聽(tīng)cfd4。線(xiàn)程池里的每一個(gè)線(xiàn)程相當(dāng)于它們所監(jiān)聽(tīng)的客戶(hù)端所對(duì)應(yīng)的服務(wù)端。當(dāng)對(duì)應(yīng)的cfd有讀寫(xiě)事件時(shí)，對(duì)應(yīng)的線(xiàn)程池里的thread會(huì)處理相應(yīng)的讀寫(xiě)業(yè)務(wù)。

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• 將主線(xiàn)程的單流程讀寫(xiě)，分散到線(xiàn)程池完成，這樣增加了同一時(shí)刻的讀寫(xiě)并行通道，并行通道數(shù)量等于線(xiàn)程池的thread數(shù)量N；
• server同時(shí)監(jiān)聽(tīng)cfd套接字?jǐn)?shù)量幾乎成倍增大，之前的全部監(jiān)控?cái)?shù)量取決于主線(xiàn)程的多路IO復(fù)用機(jī)制的最大限制（select默認(rèn)1024，epoll默認(rèn)與內(nèi)存有關(guān)，約3~6w不等）。所以該模型的理論單點(diǎn)server最高的響應(yīng)并發(fā)數(shù)量為N*（3 ~ 6w）。（N為線(xiàn)程池thread的數(shù)量，建議與cpu核心數(shù)一致）
• 如果良好的線(xiàn)程池?cái)?shù)量和CPU核心數(shù)適配，那么可以嘗試CPU核心與thread綁定，從而降低cpu的切換頻率，提高了每個(gè)thread處理業(yè)務(wù)的效率。

缺點(diǎn)：

• 雖然監(jiān)聽(tīng)的并發(fā)數(shù)量提升，但是最高讀寫(xiě)并行通道依然為N，而且多個(gè)身處被同一個(gè)thread所監(jiān)聽(tīng)的客戶(hù)端也會(huì)出現(xiàn)延遲讀寫(xiě)現(xiàn)象。實(shí)際上線(xiàn)程池里每個(gè)thread對(duì)應(yīng)客戶(hù)端的部分，相當(dāng)于模型三。

是否滿(mǎn)足實(shí)際開(kāi)發(fā)？

可以！當(dāng)前主流的線(xiàn)程池框架就是模型五，其中有Netty 和 Memcache 。

模型六：（多進(jìn)程版）單線(xiàn)程多路IO復(fù)用 + 多進(jìn)程多路IO復(fù)用（進(jìn)程池）

模型分析：

與線(xiàn)程池版沒(méi)有太大的差異。需要在服務(wù)器啟動(dòng)之前先創(chuàng)建一些守護(hù)進(jìn)程在后臺(tái)運(yùn)行。

存在的不同之處：

• ①進(jìn)程間資源不共享，而線(xiàn)程是共享資源的。進(jìn)程和線(xiàn)程的內(nèi)存布局不同導(dǎo)致主進(jìn)程不再進(jìn)行accept操作，而是將accept過(guò)程分散到每一個(gè)子進(jìn)程中
• ②進(jìn)程的資源獨(dú)立，所以主進(jìn)程如果accept成功cfd，其他的進(jìn)程是沒(méi)有辦法共享資源的，因此需要各子進(jìn)程自行accpet創(chuàng)建連接
• ③主進(jìn)程只是監(jiān)聽(tīng)listenFd狀態(tài)，一旦觸發(fā)讀事件或者有新連接請(qǐng)求，通過(guò)IPC進(jìn)程間通信（signal、mmap、fifo等方式）讓所有的子進(jìn)程們進(jìn)行競(jìng)爭(zhēng)，搶到lfd讀事件資源的子進(jìn)程會(huì)進(jìn)行accpet操作，監(jiān)聽(tīng)他們自己所創(chuàng)建出來(lái)的套接字cfd。（自己創(chuàng)建的cfd，由自己監(jiān)聽(tīng)cfd的讀寫(xiě)事件）

優(yōu)缺點(diǎn)：

與線(xiàn)程池版本沒(méi)有太大差異

優(yōu)點(diǎn)：

• 由于進(jìn)程間的資源獨(dú)立，盡管是父子進(jìn)程，也是讀時(shí)共享，寫(xiě)時(shí)復(fù)制。因此多進(jìn)程模型安全穩(wěn)定性較強(qiáng)，各自進(jìn)程互不干擾。Nginx就是使用進(jìn)程池的框架實(shí)現(xiàn)的。不過(guò)方案與標(biāo)準(zhǔn)的多 Reactor 多進(jìn)程有些差異。具體差異表現(xiàn)在主進(jìn)程中僅僅用來(lái)初始化 socket，并沒(méi)有創(chuàng)建 mainReactor 來(lái) accept 連接，而是由子進(jìn)程的 Reactor 來(lái) accept 連接，通過(guò)鎖來(lái)控制一次只有一個(gè)子進(jìn)程進(jìn)行 accept（防止出現(xiàn)驚群現(xiàn)象），子進(jìn)程 accept 新連接后就放到自己的 Reactor 進(jìn)行處理，不會(huì)再分配給其他子進(jìn)程。

缺點(diǎn)：

• 多進(jìn)程內(nèi)存資源空間占用得稍微大一些

模型七：?jiǎn)尉€(xiàn)程多路I/O復(fù)用+多線(xiàn)程多路I/O復(fù)用+多線(xiàn)程

模型分析：

• ①server在啟動(dòng)監(jiān)聽(tīng)之前，開(kāi)辟固定數(shù)量N個(gè)線(xiàn)程，創(chuàng)建thread pool線(xiàn)程池。
• ②主線(xiàn)程創(chuàng)建lfd之后，采用多路IO復(fù)用機(jī)制進(jìn)行IO狀態(tài)的阻塞監(jiān)聽(tīng)。當(dāng)有client1客戶(hù)端connect請(qǐng)求，多路IO復(fù)用機(jī)制檢測(cè)到lfd觸發(fā)讀事件，則會(huì)進(jìn)行accept建立連接，并把a(bǔ)ccept后新創(chuàng)建的cfd1分發(fā)給thread pool中的某個(gè)線(xiàn)程進(jìn)行監(jiān)聽(tīng)。
• ③線(xiàn)程池中的每個(gè)thread都啟動(dòng)多路IO復(fù)用機(jī)制，用來(lái)監(jiān)聽(tīng)主線(xiàn)程分發(fā)下來(lái)的socket套接字cfd。一旦某個(gè)被監(jiān)聽(tīng)的cfd被觸發(fā)了讀寫(xiě)事件，該線(xiàn)程池里的thread會(huì)立即開(kāi)辟他的一個(gè)子線(xiàn)程與cfd進(jìn)行讀寫(xiě)業(yè)務(wù)操作。
• ④當(dāng)某個(gè)讀寫(xiě)線(xiàn)程完成當(dāng)前讀寫(xiě)業(yè)務(wù)時(shí)，如果當(dāng)前套接字沒(méi)有被關(guān)閉，那么該線(xiàn)程會(huì)將當(dāng)前的cfd套接字重新加回線(xiàn)程池的監(jiān)聽(tīng)線(xiàn)程中，同時(shí)自身銷(xiāo)毀。

優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

• 在模型五的基礎(chǔ)上，除了能夠保證同時(shí)響應(yīng)的最高并發(fā)數(shù)，又能解決了讀寫(xiě)并行通道被局限的問(wèn)題。
• 同一時(shí)刻的讀寫(xiě)并行通道達(dá)到最大極限，一個(gè)客戶(hù)端可以對(duì)應(yīng)一個(gè)單獨(dú)線(xiàn)程處理讀寫(xiě)業(yè)務(wù)。讀寫(xiě)并行通道與客戶(hù)端的數(shù)量是1 ：1關(guān)系。

缺點(diǎn)：

• 該模型過(guò)于理想化，因?yàn)橐骳pu的核心數(shù)足夠大
• 如果硬件cpu數(shù)量可數(shù)（目前的硬件情況就是cpu可數(shù)），那么該模型將造成大量的cpu切換成本。為了保證讀寫(xiě)并行通道與客戶(hù)端可以一對(duì)一服務(wù)，那么server需要開(kāi)辟的線(xiàn)程數(shù)量就要與客戶(hù)端一致，那么線(xiàn)程池中多路IO復(fù)用的監(jiān)聽(tīng)線(xiàn)程池綁定CPU數(shù)量將會(huì)變得毫無(wú)意義。（因?yàn)槭褂枚嗦稩O復(fù)用機(jī)制，就是為了達(dá)到1個(gè)線(xiàn)程可以監(jiān)聽(tīng)多個(gè)client。如果現(xiàn)在的線(xiàn)程數(shù)量已經(jīng)跟客戶(hù)端數(shù)量一致了，那多路IO復(fù)用就沒(méi)意義了）
• 如果每個(gè)臨時(shí)的讀寫(xiě)線(xiàn)程都能夠綁定一個(gè)單獨(dú)的CPU，那么此模型將會(huì)是最優(yōu)模型。但是目前的CPU數(shù)量無(wú)法與客戶(hù)端的數(shù)量達(dá)到一個(gè)量級(jí)，還差得遠(yuǎn)。

八 、總結(jié)

• 上面整理了7種server的服務(wù)器處理結(jié)構(gòu)模型，對(duì)于應(yīng)付高并發(fā)和高CPU利用率的模型，目前采用最多的是模型五，其中Nginx就是類(lèi)似模型五進(jìn)程版的改版。
• 并發(fā)模型并且設(shè)計(jì)得越復(fù)雜越好，也不是線(xiàn)程開(kāi)辟越多越好。真實(shí)設(shè)計(jì)開(kāi)發(fā)中需要考慮硬件的利用和CPU切換成本的開(kāi)銷(xiāo)。模型六的設(shè)計(jì)極為復(fù)雜，線(xiàn)程較多，但以當(dāng)今的硬件能力無(wú)法實(shí)現(xiàn)，反倒導(dǎo)致該模型性能級(jí)差。所以對(duì)于不同的業(yè)務(wù)場(chǎng)景要選擇適合的模型構(gòu)建，并不是說(shuō)固定要使用哪一個(gè)，要根據(jù)實(shí)際靈活變動(dòng)。