兩種高效的事件處理模式

服務器程序通常需要處理三類事件：I/O 事件、信號及定時事件。有兩種高效的事件處理模式：Reactor和 Proactor，同步 I/O 模型通常用于實現Reactor 模式，異步 I/O 模型通常用于實現 Proactor 模式。

無論是 Reactor，還是 Proactor，都是一種基于「事件分發」的網絡編程模式，區別在于 Reactor 模式是基于「待完成」的 I/O 事件，而 Proactor 模式則是基于「已完成」的 I/O 事件

Reactor可以理解為：來了事件是由操作系統通知應用程序，讓應用程序來處理。又因為【內核中的數據準備階段和數據就緒并由內核態切換到用戶態】這兩個過程對應用層來說是需要主動調用read來等待的，所以Reactor一般都是用同步IO實現。

Proactor可以理解為：來了事件是由操作系統處理好了之后再通知應用程序。又因為【內核中會由異步線程把數據準備好并且處理好了之后，直接通過信號中斷告訴應用層】，對于應用程序來說，得到的是已經完成讀寫的事件，這個過程不需要等待。因此Proactor一般都是用異步IO實現的。

Linux基本上逐步實現了POSIX兼容，但并沒有參加正式的POSIX認證。由于Linux下的異步IO不完善，aio_read,aio_write系列函數是由POSIX定義的異步操作接口，不是真正操作系統級別支持的，而是在用戶空間模擬出來的異步，并且僅支持本地文件的aio異步操作，網絡編程中的socket是不支持的。所以本文沒有講述異步IO實現Proactor模式，取而代之的是同步IO模擬實現Proactor模式。

①同步IO實現reactor模式：主線程只負責監聽lfd，accept成功之后把新創建的cfd交給子線程。子線程再通過IO多路復用去監聽cfd的讀寫數據，并且處理客戶端業務。（主線程把已被觸發但是還未完成的事件分發給子線程）

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

②同步IO模擬proactor模式：是主線程accpet監聽lfd，并且lfd讀事件觸發時，建立連接并創建cfd，并且通過epoll_ctl把cfd注冊到內核的監聽樹中，等到該socket的讀事件就緒時，主線程進行讀操作，把讀到的內容交給子線程去進行業務處理，然后子線程處理完業務之后把該socketfd又注冊為寫時間就緒，并且把數據交回給主線程，由主線程寫回給客戶端。

（主線程模擬真實Proactor模式中的異步線程，把已完成的事件分發給子線程）

下面的并發模型中，常用的是:

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

2??模型五線程池版本 （同步IO實現reactor模式）

在客戶端數量非常多的時候適合用模型五，但是在客戶端數量不多的時候使用模型四可能會效率更好，因為模型四的線程數量更少，減少CPU切換線程的頻率。

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

理論上 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）模擬出來的異步模型

服務器開發常見的并發模型

只要是做服務器開發，那么常見的模型是通用的，C/C++/go等等都是通用的，因為這是一種設計思想。

其中模型四和模型五是實際開發中主流的，而模型六過于理想化目前的硬件無法實現。

模型一：單線程accept（無IO復用）

模型分析：

• ①主線程執行阻塞accept，每次客戶端connect請求連接過來，主線程中的accept響應并建立連接
• ②創建連接成功之后，得到新的套接字文件描述符cfd（用于與客戶端通信），然后在主線程串行處理套接字讀寫，并處理業務。
• ③在②的處理業務時，如果有新的客戶端發送請求連接，會被阻塞，服務器無響應，直到當前的cfd全部業務處理完畢，重新回到accept阻塞監聽狀態時，才會從請求隊列中選取第一個lfd進行連接。

優缺點：

優點：

• socket編程流程清晰且簡單，適合學習使用，了解socket基本編程流程。

缺點：

• 該模型并非并發模型，是串行的服務器，同一時刻，監聽并響應最大的網絡請求量為1。即并發量為1。
• 僅適合學習基本socket編程，不適合任何服務器Server構建。

模型二：單線程accept + 多線程讀寫業務（無IO復用）

模型分析：

• ①主線程執行accept阻塞監聽，每當有客戶端connect連接請求過來，主線程中的accept響應并且與客戶端建立連接
• ②創建連接成功后得到新的cfd，然后再thread_create一個新的線程用來處理客戶端的讀寫業務，并且主線程馬上回到accept阻塞監聽繼續等待新客戶端的連接請求
• ③這個新的線程通過套接字cfd與客戶端進行通信讀寫
• ④服務器在②處理業務中，如果有新客戶端發送申請連接過來，主線程accept依然會響應并且簡歷連接，重復②過程。

優缺點：

優點：

• 基于模型一作了改進，支持了并發
• 使用靈活，一個client對應一個thread單獨處理，server處理業務的內聚程度高（一個好的內聚模塊應當恰好做一件事）?？蛻舳藷o論如何寫，服務端都會有一個線程做資源響應。

缺點：

• 隨著客戶端的數量增多，需要開辟的線程也增加，客戶端與服務端線程數量是1：1正比關系。因此對于高并發場景，線程數量收到硬件的瓶頸制約。線程過多也會增加CPU的切換成本，降低CPU的利用率。
• 對于長連接，客戶端一旦沒有業務讀寫操作，只要客戶端不關閉，服務端的對應線程就必須要保持連接（心跳包、健康監測等機制），占用連接資源和線程的開銷
• 僅適合客戶端數量不大，并且是可控的場景來使用
• 僅適合學習基本的socket編程，不適合做并發服務器

模型三：單線程多路IO復用

模型分析：

• ①主線程main thread 創建 lfd之后，采用多路IO復用機制（如select和epoll）進行IO狀態阻塞監聽。有client1客戶端 connect 請求， IO復用機制檢測到lfd觸發事件讀寫，則進行accept建立連接，并將新生成的cfd1加入到監聽IO集合中。
• ②client1 再次進行正常讀寫業務請求，主線程的多路IO復用機制阻塞返回，主線程與client1進行讀寫通信業務。等到讀寫業務結束后，會再次返回多路IO復用的地方進行阻塞監聽。
• ③如果client1正在進行讀寫業務時，server依然在主線程執行流程中繼續執行，此時如果有新的客戶端申請連接請求，server將沒有辦法及時響應（因為是單線程，server正在讀寫），將會把這些還沒來得及響應的請求加入阻塞隊列中。
• ④等到server處理完一個客戶端連接的讀寫操作時，繼續回到多路IO復用機制處阻塞，其他的連接如果再發送連接請求過來的話，會繼續重復②③流程。

優缺點：

優點：

• 單線程/單進程解決了可以同時監聽多個客戶端讀寫狀態的模型，不需要1：1與客戶端的線程數量關系。而是1：n；
• 多路IO復用阻塞，不需要一直輪詢，所以不會浪費CPU資源，CPU利用效率較高。

缺點：

• 因為是單線程/單線程，雖然可以監聽多個客戶端的讀寫狀態，但是在同一時間內，只能處理一個客戶端的讀寫操作，實際上讀寫的業務并發為1；
• 多客戶端訪問服務器，但是業務為串行執行，大量請求會有排隊延遲現象。如圖中⑤所示，當client3占據主線程流程時， client1和client2流程會卡在IO復用，等待下次監聽觸發事件。

是否滿足實際開發？

可以！該模型編寫代碼較簡單，雖然有延遲現象，但是畢竟多路IO復用機制阻塞，不會占用CPU資源，如果并發請求量比較小，客戶端數量可數，允許信息有一點點延遲，可以使用該模型。

比如Redis就是采用該模型設計的，因為Redis業務處理主要是在內存中完成的，操作速度很快，性能瓶頸不在CPU上。

模型四：單線程多路IO復用 + 多線程業務工作池

模型分析：

前兩步跟模型三一致

• ①主線程main thread 創建 lfd之后，采用多路IO復用機制（如select和epoll）進行IO狀態阻塞監聽。有client1客戶端 connect 請求， IO復用機制檢測到lfd觸發事件讀寫，則進行accept建立連接，并將新生成的cfd1加入到監聽IO集合中。
• ②當cfd1有可讀消息，觸發讀事件，并且進行讀寫消息。
• ③主線程按照固定的協議讀取消息，并且交給worker pool工作線程池，工作線程池在server啟動之前就已經開啟固定數量的線程，里面的線程只處理消息業務，不進行套接字讀寫操作。
• ④工作池處理完業務，觸發cfd1寫事件，將要回發客戶端的數據消息通過主線程寫回給客戶端

優缺點：

優點：

• 相比于模型三而言，設計了一個worker pool業務線程池，將業務處理部分從主線程抽離出來，為主線程分擔了業務處理的工作，減少了因為單線程的串行執行業務機制，多客戶端對server的大量請求造成排隊延遲的時間。就是說主線程讀完數據之后馬上就丟給了線程池去處理，然后馬上回到多路IO復用的阻塞監聽狀態?？s短了其他客戶端的等待連接時間。
• 由于是單線程，實際上讀寫的業務并發還是為1，但是業務流程的并發數為worker pool線程池里的線程數量，加快了業務處理并行效率。

缺點：

• 讀寫依然是主線程單獨處理，最高的讀寫并行通道依然是1，導致當前服務器的并發性能依然沒有提升，只是響應任務的速度快了。每個客戶端的排隊時間短了，但因為還是只有一個通道進行讀寫操作，因此總體的完成度跟模型3是差不多的。
• 雖然多個worker線程池處理業務，但是最后返回給客戶端依舊也需要排隊。因為出口還是只有read+write 這1個通道。因此業務是可以并行了，但是總體的效率是不變的。
• 模型三是客戶端向server發起請求時需要排隊，模型四是業務處理完之后回寫客戶端需要排隊。

是否滿足實際開發？

可以！模型三跟模型四的總體并發效率差不多，因為還是一個線程進行讀寫。但是對于客戶端的體驗來說，會覺得響應速度變快，減少了在服務器的排隊時間。如果客戶端數量不多，并且各個客戶端的邏輯業務有并行需求的話適合用該模型。

模型五：單線程多路IO復用 + 多線程多路IO復用（線程池）實際中最常用

模型分析：

• ①server在啟動監聽之前，需要創建固定數量N的線程，作為thread pool線程池。
• ②主線程創建lfd之后，采用多路IO復用機制（如select、epoll）進行IO狀態阻塞監聽。有client1客戶端 connect請求，IO復用機制檢測到lfd觸發讀事件，則進行accept建立連接，并且將新創建的cfd1分發給thread pool線程池中的某個線程監聽。
• ③thread pool中的每個thread都啟動多路IO復用機制，用來監聽主線程建立成功并且分發下來的socket套接字（cfd）。
• ④如圖，thread1監聽cfd1、cfd2，thread2監聽cfd3，thread3監聽cfd4。線程池里的每一個線程相當于它們所監聽的客戶端所對應的服務端。當對應的cfd有讀寫事件時，對應的線程池里的thread會處理相應的讀寫業務。

優缺點：

優點：

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

缺點：

• 雖然監聽的并發數量提升，但是最高讀寫并行通道依然為N，而且多個身處被同一個thread所監聽的客戶端也會出現延遲讀寫現象。實際上線程池里每個thread對應客戶端的部分，相當于模型三。

是否滿足實際開發？

可以！當前主流的線程池框架就是模型五，其中有Netty 和 Memcache 。

模型六：（多進程版）單線程多路IO復用 + 多進程多路IO復用（進程池）

模型分析：

與線程池版沒有太大的差異。需要在服務器啟動之前先創建一些守護進程在后臺運行。

存在的不同之處：

• ①進程間資源不共享，而線程是共享資源的。進程和線程的內存布局不同導致主進程不再進行accept操作，而是將accept過程分散到每一個子進程中
• ②進程的資源獨立，所以主進程如果accept成功cfd，其他的進程是沒有辦法共享資源的，因此需要各子進程自行accpet創建連接
• ③主進程只是監聽listenFd狀態，一旦觸發讀事件或者有新連接請求，通過IPC進程間通信（signal、mmap、fifo等方式）讓所有的子進程們進行競爭，搶到lfd讀事件資源的子進程會進行accpet操作，監聽他們自己所創建出來的套接字cfd。（自己創建的cfd，由自己監聽cfd的讀寫事件）

優缺點：

與線程池版本沒有太大差異

優點：

• 由于進程間的資源獨立，盡管是父子進程，也是讀時共享，寫時復制。因此多進程模型安全穩定性較強，各自進程互不干擾。Nginx就是使用進程池的框架實現的。不過方案與標準的多 Reactor 多進程有些差異。具體差異表現在主進程中僅僅用來初始化 socket，并沒有創建 mainReactor 來 accept 連接，而是由子進程的 Reactor 來 accept 連接，通過鎖來控制一次只有一個子進程進行 accept（防止出現驚群現象），子進程 accept 新連接后就放到自己的 Reactor 進行處理，不會再分配給其他子進程。

缺點：

• 多進程內存資源空間占用得稍微大一些

模型七：單線程多路I/O復用+多線程多路I/O復用+多線程

模型分析：

• ①server在啟動監聽之前，開辟固定數量N個線程，創建thread pool線程池。
• ②主線程創建lfd之后，采用多路IO復用機制進行IO狀態的阻塞監聽。當有client1客戶端connect請求，多路IO復用機制檢測到lfd觸發讀事件，則會進行accept建立連接，并把accept后新創建的cfd1分發給thread pool中的某個線程進行監聽。
• ③線程池中的每個thread都啟動多路IO復用機制，用來監聽主線程分發下來的socket套接字cfd。一旦某個被監聽的cfd被觸發了讀寫事件，該線程池里的thread會立即開辟他的一個子線程與cfd進行讀寫業務操作。
• ④當某個讀寫線程完成當前讀寫業務時，如果當前套接字沒有被關閉，那么該線程會將當前的cfd套接字重新加回線程池的監聽線程中，同時自身銷毀。

優缺點：

優點：

• 在模型五的基礎上，除了能夠保證同時響應的最高并發數，又能解決了讀寫并行通道被局限的問題。
• 同一時刻的讀寫并行通道達到最大極限，一個客戶端可以對應一個單獨線程處理讀寫業務。讀寫并行通道與客戶端的數量是1 ：1關系。

缺點：

• 該模型過于理想化，因為要求cpu的核心數足夠大
• 如果硬件cpu數量可數（目前的硬件情況就是cpu可數），那么該模型將造成大量的cpu切換成本。為了保證讀寫并行通道與客戶端可以一對一服務，那么server需要開辟的線程數量就要與客戶端一致，那么線程池中多路IO復用的監聽線程池綁定CPU數量將會變得毫無意義。（因為使用多路IO復用機制，就是為了達到1個線程可以監聽多個client。如果現在的線程數量已經跟客戶端數量一致了，那多路IO復用就沒意義了）
• 如果每個臨時的讀寫線程都能夠綁定一個單獨的CPU，那么此模型將會是最優模型。但是目前的CPU數量無法與客戶端的數量達到一個量級，還差得遠。

八 、總結

• 上面整理了7種server的服務器處理結構模型，對于應付高并發和高CPU利用率的模型，目前采用最多的是模型五，其中Nginx就是類似模型五進程版的改版。
• 并發模型并且設計得越復雜越好，也不是線程開辟越多越好。真實設計開發中需要考慮硬件的利用和CPU切換成本的開銷。模型六的設計極為復雜，線程較多，但以當今的硬件能力無法實現，反倒導致該模型性能級差。所以對于不同的業務場景要選擇適合的模型構建，并不是說固定要使用哪一個，要根據實際靈活變動。