盗墓笔记,遮天

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

如何理解高性能網(wǎng)絡(luò)模型？這篇文章說(shuō)透了

【稿件】本文旨在為大家提供有用的概覽以及網(wǎng)絡(luò)服務(wù)模型的比較，以揭開(kāi)設(shè)計(jì)和實(shí)現(xiàn)高性能網(wǎng)絡(luò)架構(gòu)的神秘面紗。

目前成都創(chuàng)新互聯(lián)已為上千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機(jī)、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、彌渡網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

服務(wù)端處理網(wǎng)絡(luò)請(qǐng)求

首先看看服務(wù)端處理網(wǎng)絡(luò)請(qǐng)求的典型過(guò)程：

由上圖可以看到，主要處理步驟包括：

獲取請(qǐng)求數(shù)據(jù)，客戶端與服務(wù)器建立連接發(fā)出請(qǐng)求，服務(wù)器接受請(qǐng)求（1-3）。
構(gòu)建響應(yīng)，當(dāng)服務(wù)器接收完請(qǐng)求，并在用戶空間處理客戶端的請(qǐng)求，直到構(gòu)建響應(yīng)完成（4）。
返回?cái)?shù)據(jù)，服務(wù)器將已構(gòu)建好的響應(yīng)再通過(guò)內(nèi)核空間的網(wǎng)絡(luò) I/O 發(fā)還給客戶端（5-7）。

設(shè)計(jì)服務(wù)端并發(fā)模型時(shí)，主要有如下兩個(gè)關(guān)鍵點(diǎn)：

服務(wù)器如何管理連接，獲取輸入數(shù)據(jù)。
服務(wù)器如何處理請(qǐng)求。

以上兩個(gè)關(guān)鍵點(diǎn)最終都與操作系統(tǒng)的 I/O 模型以及線程(進(jìn)程)模型相關(guān)，下面詳細(xì)介紹這兩個(gè)模型。

I/O 模型

介紹操作系統(tǒng)的 I/O 模型之前，先了解一下幾個(gè)概念：

阻塞調(diào)用與非阻塞調(diào)用。
阻塞調(diào)用是指調(diào)用結(jié)果返回之前，當(dāng)前線程會(huì)被掛起。調(diào)用線程只有在得到結(jié)果之后才會(huì)返回。
非阻塞調(diào)用指在不能立刻得到結(jié)果之前，該調(diào)用不會(huì)阻塞當(dāng)前線程。

兩者的***區(qū)別在于被調(diào)用方在收到請(qǐng)求到返回結(jié)果之前的這段時(shí)間內(nèi)，調(diào)用方是否一直在等待。

阻塞是指調(diào)用方一直在等待而且別的事情什么都不做；非阻塞是指調(diào)用方先去忙別的事情。

同步處理與異步處理

同步處理是指被調(diào)用方得到最終結(jié)果之后才返回給調(diào)用方；異步處理是指被調(diào)用方先返回應(yīng)答，然后再計(jì)算調(diào)用結(jié)果，計(jì)算完最終結(jié)果后再通知并返回給調(diào)用方。

阻塞、非阻塞和同步、異步的區(qū)別

阻塞、非阻塞和同步、異步其實(shí)針對(duì)的對(duì)象是不一樣的：
阻塞、非阻塞的討論對(duì)象是調(diào)用者。

同步、異步的討論對(duì)象是被調(diào)用者。

recvfrom 函數(shù)

recvfrom 函數(shù)(經(jīng) Socket 接收數(shù)據(jù))，這里把它視為系統(tǒng)調(diào)用。

一個(gè)輸入操作通常包括兩個(gè)不同的階段：

等待數(shù)據(jù)準(zhǔn)備好
從內(nèi)核向進(jìn)程復(fù)制數(shù)據(jù)

對(duì)于一個(gè)套接字上的輸入操作，***步通常涉及等待數(shù)據(jù)從網(wǎng)絡(luò)中到達(dá)。當(dāng)所等待分組到達(dá)時(shí)，它被復(fù)制到內(nèi)核中的某個(gè)緩沖區(qū)。第二步就是把數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到應(yīng)用進(jìn)程緩沖區(qū)。

實(shí)際應(yīng)用程序在系統(tǒng)調(diào)用完成上面的 2 步操作時(shí)，調(diào)用方式的阻塞、非阻塞，操作系統(tǒng)在處理應(yīng)用程序請(qǐng)求時(shí)，處理方式的同步、異步處理的不同，可以分為 5 種 I/O 模型。（參考《UNIX網(wǎng)絡(luò)編程卷1》）

阻塞式 I/O 模型(blocking I/O）

在阻塞式 I/O 模型中，應(yīng)用程序在從調(diào)用 recvfrom 開(kāi)始到它返回有數(shù)據(jù)報(bào)準(zhǔn)備好這段時(shí)間是阻塞的，recvfrom 返回成功后，應(yīng)用進(jìn)程開(kāi)始處理數(shù)據(jù)報(bào)。

比喻：一個(gè)人在釣魚，當(dāng)沒(méi)魚上鉤時(shí)，就坐在岸邊一直等。

優(yōu)點(diǎn)：程序簡(jiǎn)單，在阻塞等待數(shù)據(jù)期間進(jìn)程/線程掛起，基本不會(huì)占用 CPU 資源。

缺點(diǎn)：每個(gè)連接需要獨(dú)立的進(jìn)程/線程單獨(dú)處理，當(dāng)并發(fā)請(qǐng)求量大時(shí)為了維護(hù)程序，內(nèi)存、線程切換開(kāi)銷較大，這種模型在實(shí)際生產(chǎn)中很少使用。

非阻塞式 I/O 模型(non-blocking I/O）

在非阻塞式 I/O 模型中，應(yīng)用程序把一個(gè)套接口設(shè)置為非阻塞，就是告訴內(nèi)核，當(dāng)所請(qǐng)求的 I/O 操作無(wú)法完成時(shí)，不要將進(jìn)程睡眠。

而是返回一個(gè)錯(cuò)誤，應(yīng)用程序基于 I/O 操作函數(shù)將不斷的輪詢數(shù)據(jù)是否已經(jīng)準(zhǔn)備好，如果沒(méi)有準(zhǔn)備好，繼續(xù)輪詢，直到數(shù)據(jù)準(zhǔn)備好為止。

比喻：邊釣魚邊玩手機(jī)，隔會(huì)再看看有沒(méi)有魚上鉤，有的話就迅速拉桿。

優(yōu)點(diǎn)：不會(huì)阻塞在內(nèi)核的等待數(shù)據(jù)過(guò)程，每次發(fā)起的 I/O 請(qǐng)求可以立即返回，不用阻塞等待，實(shí)時(shí)性較好。

缺點(diǎn)：輪詢將會(huì)不斷地詢問(wèn)內(nèi)核，這將占用大量的 CPU 時(shí)間，系統(tǒng)資源利用率較低，所以一般 Web 服務(wù)器不使用這種 I/O 模型。

I/O 復(fù)用模型(I/O multiplexing）

在 I/O 復(fù)用模型中，會(huì)用到 Select 或 Poll 函數(shù)或 Epoll 函數(shù)(Linux 2.6 以后的內(nèi)核開(kāi)始支持)，這兩個(gè)函數(shù)也會(huì)使進(jìn)程阻塞，但是和阻塞 I/O 有所不同。

這兩個(gè)函數(shù)可以同時(shí)阻塞多個(gè) I/O 操作，而且可以同時(shí)對(duì)多個(gè)讀操作，多個(gè)寫操作的 I/O 函數(shù)進(jìn)行檢測(cè)，直到有數(shù)據(jù)可讀或可寫時(shí)，才真正調(diào)用 I/O 操作函數(shù)。

比喻：放了一堆魚竿，在岸邊一直守著這堆魚竿，沒(méi)魚上鉤就玩手機(jī)。

優(yōu)點(diǎn)：可以基于一個(gè)阻塞對(duì)象，同時(shí)在多個(gè)描述符上等待就緒，而不是使用多個(gè)線程(每個(gè)文件描述符一個(gè)線程)，這樣可以大大節(jié)省系統(tǒng)資源。

缺點(diǎn)：當(dāng)連接數(shù)較少時(shí)效率相比多線程+阻塞 I/O 模型效率較低，可能延遲更大，因?yàn)閱蝹€(gè)連接處理需要 2 次系統(tǒng)調(diào)用，占用時(shí)間會(huì)有增加。

信號(hào)驅(qū)動(dòng)式 I/O 模型（signal-driven I/O)

在信號(hào)驅(qū)動(dòng)式 I/O 模型中，應(yīng)用程序使用套接口進(jìn)行信號(hào)驅(qū)動(dòng) I/O，并安裝一個(gè)信號(hào)處理函數(shù)，進(jìn)程繼續(xù)運(yùn)行并不阻塞。

當(dāng)數(shù)據(jù)準(zhǔn)備好時(shí)，進(jìn)程會(huì)收到一個(gè) SIGIO 信號(hào)，可以在信號(hào)處理函數(shù)中調(diào)用 I/O 操作函數(shù)處理數(shù)據(jù)。

比喻：魚竿上系了個(gè)鈴鐺，當(dāng)鈴鐺響，就知道魚上鉤，然后可以專心玩手機(jī)。

優(yōu)點(diǎn)：線程并沒(méi)有在等待數(shù)據(jù)時(shí)被阻塞，可以提高資源的利用率。

缺點(diǎn)：信號(hào) I/O 在大量 IO 操作時(shí)可能會(huì)因?yàn)樾盘?hào)隊(duì)列溢出導(dǎo)致沒(méi)法通知。

信號(hào)驅(qū)動(dòng) I/O 盡管對(duì)于處理 UDP 套接字來(lái)說(shuō)有用，即這種信號(hào)通知意味著到達(dá)一個(gè)數(shù)據(jù)報(bào)，或者返回一個(gè)異步錯(cuò)誤。

但是，對(duì)于 TCP 而言，信號(hào)驅(qū)動(dòng)的 I/O 方式近乎無(wú)用，因?yàn)閷?dǎo)致這種通知的條件為數(shù)眾多，每一個(gè)來(lái)進(jìn)行判別會(huì)消耗很大資源，與前幾種方式相比優(yōu)勢(shì)盡失。

異步 I/O 模型（asynchronous I/O）

由 POSIX 規(guī)范定義，應(yīng)用程序告知內(nèi)核啟動(dòng)某個(gè)操作，并讓內(nèi)核在整個(gè)操作（包括將數(shù)據(jù)從內(nèi)核拷貝到應(yīng)用程序的緩沖區(qū)）完成后通知應(yīng)用程序。

這種模型與信號(hào)驅(qū)動(dòng)模型的主要區(qū)別在于：信號(hào)驅(qū)動(dòng) I/O 是由內(nèi)核通知應(yīng)用程序何時(shí)啟動(dòng)一個(gè) I/O 操作，而異步 I/O 模型是由內(nèi)核通知應(yīng)用程序 I/O 操作何時(shí)完成。

優(yōu)點(diǎn)：異步 I/O 能夠充分利用 DMA 特性，讓 I/O 操作與計(jì)算重疊。

缺點(diǎn)：要實(shí)現(xiàn)真正的異步 I/O，操作系統(tǒng)需要做大量的工作。目前 Windows 下通過(guò) IOCP 實(shí)現(xiàn)了真正的異步 I/O。

而在 Linux 系統(tǒng)下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下實(shí)現(xiàn)高并發(fā)網(wǎng)絡(luò)編程時(shí)都是以 IO 復(fù)用模型模式為主。

5 種 I/O 模型總結(jié)

從上圖中我們可以看出，越往后，阻塞越少，理論上效率也是***。

這五種 I/O 模型中，前四種屬于同步 I/O，因?yàn)槠渲姓嬲?I/O 操作(recvfrom)將阻塞進(jìn)程/線程，只有異步 I/O 模型才與 POSIX 定義的異步 I/O 相匹配。

線程模型

介紹完服務(wù)器如何基于 I/O 模型管理連接，獲取輸入數(shù)據(jù)，下面介紹基于進(jìn)程/線程模型，服務(wù)器如何處理請(qǐng)求。

值得說(shuō)明的是，具體選擇線程還是進(jìn)程，更多是與平臺(tái)及編程語(yǔ)言相關(guān)。

例如 C 語(yǔ)言使用線程和進(jìn)程都可以(例如 Nginx 使用進(jìn)程，Memcached 使用線程)，Java 語(yǔ)言一般使用線程(例如 Netty)，為了描述方便，下面都使用線程來(lái)進(jìn)行描述。

傳統(tǒng)阻塞 I/O 服務(wù)模型

特點(diǎn)：

采用阻塞式 I/O 模型獲取輸入數(shù)據(jù)。
每個(gè)連接都需要獨(dú)立的線程完成數(shù)據(jù)輸入，業(yè)務(wù)處理，數(shù)據(jù)返回的完整操作。

存在問(wèn)題：

當(dāng)并發(fā)數(shù)較大時(shí)，需要?jiǎng)?chuàng)建大量線程來(lái)處理連接，系統(tǒng)資源占用較大。
連接建立后，如果當(dāng)前線程暫時(shí)沒(méi)有數(shù)據(jù)可讀，則線程就阻塞在 Read 操作上，造成線程資源浪費(fèi)。

Reactor 模式

針對(duì)傳統(tǒng)阻塞 I/O 服務(wù)模型的 2 個(gè)缺點(diǎn)，比較常見(jiàn)的有如下解決方案：

基于 I/O 復(fù)用模型，多個(gè)連接共用一個(gè)阻塞對(duì)象，應(yīng)用程序只需要在一個(gè)阻塞對(duì)象上等待，無(wú)需阻塞等待所有連接。

當(dāng)某條連接有新的數(shù)據(jù)可以處理時(shí)，操作系統(tǒng)通知應(yīng)用程序，線程從阻塞狀態(tài)返回，開(kāi)始進(jìn)行業(yè)務(wù)處理。

基于線程池復(fù)用線程資源，不必再為每個(gè)連接創(chuàng)建線程，將連接完成后的業(yè)務(wù)處理任務(wù)分配給線程進(jìn)行處理，一個(gè)線程可以處理多個(gè)連接的業(yè)務(wù)。

I/O 復(fù)用結(jié)合線程池，這就是 Reactor 模式基本設(shè)計(jì)思想，如下圖：

Reactor 模式，是指通過(guò)一個(gè)或多個(gè)輸入同時(shí)傳遞給服務(wù)處理器的服務(wù)請(qǐng)求的事件驅(qū)動(dòng)處理模式。

服務(wù)端程序處理傳入多路請(qǐng)求，并將它們同步分派給請(qǐng)求對(duì)應(yīng)的處理線程，Reactor 模式也叫 Dispatcher 模式。

即 I/O 多了復(fù)用統(tǒng)一監(jiān)聽(tīng)事件，收到事件后分發(fā)(Dispatch 給某進(jìn)程)，是編寫高性能網(wǎng)絡(luò)服務(wù)器的必備技術(shù)之一。

Reactor 模式中有 2 個(gè)關(guān)鍵組成：

Reactor，Reactor 在一個(gè)單獨(dú)的線程中運(yùn)行，負(fù)責(zé)監(jiān)聽(tīng)和分發(fā)事件，分發(fā)給適當(dāng)?shù)奶幚沓绦騺?lái)對(duì) IO 事件做出反應(yīng)。它就像公司的電話接線員，它接聽(tīng)來(lái)自客戶的電話并將線路轉(zhuǎn)移到適當(dāng)?shù)穆?lián)系人。
Handlers，處理程序執(zhí)行 I/O 事件要完成的實(shí)際事件，類似于客戶想要與之交談的公司中的實(shí)際官員。Reactor 通過(guò)調(diào)度適當(dāng)?shù)奶幚沓绦騺?lái)響應(yīng) I/O 事件，處理程序執(zhí)行非阻塞操作。

根據(jù) Reactor 的數(shù)量和處理資源池線程的數(shù)量不同，有 3 種典型的實(shí)現(xiàn)：

單 Reactor 單線程
單 Reactor 多線程
主從 Reactor 多線程

下面詳細(xì)介紹這 3 種實(shí)現(xiàn)方式。

單 Reactor 單線程

其中，Select 是前面 I/O 復(fù)用模型介紹的標(biāo)準(zhǔn)網(wǎng)絡(luò)編程 API，可以實(shí)現(xiàn)應(yīng)用程序通過(guò)一個(gè)阻塞對(duì)象監(jiān)聽(tīng)多路連接請(qǐng)求，其他方案示意圖類似。

方案說(shuō)明：

Reactor 對(duì)象通過(guò) Select 監(jiān)控客戶端請(qǐng)求事件，收到事件后通過(guò) Dispatch 進(jìn)行分發(fā)。

如果是建立連接請(qǐng)求事件，則由 Acceptor 通過(guò) Accept 處理連接請(qǐng)求，然后創(chuàng)建一個(gè) Handler 對(duì)象處理連接完成后的后續(xù)業(yè)務(wù)處理。
如果不是建立連接事件，則 Reactor 會(huì)分發(fā)調(diào)用連接對(duì)應(yīng)的 Handler 來(lái)響應(yīng)。
Handler 會(huì)完成 Read→業(yè)務(wù)處理→Send 的完整業(yè)務(wù)流程。

優(yōu)點(diǎn)：模型簡(jiǎn)單，沒(méi)有多線程、進(jìn)程通信、競(jìng)爭(zhēng)的問(wèn)題，全部都在一個(gè)線程中完成。

缺點(diǎn)：性能問(wèn)題，只有一個(gè)線程，無(wú)法完全發(fā)揮多核 CPU 的性能。Handler 在處理某個(gè)連接上的業(yè)務(wù)時(shí)，整個(gè)進(jìn)程無(wú)法處理其他連接事件，很容易導(dǎo)致性能瓶頸。

可靠性問(wèn)題，線程意外跑飛，或者進(jìn)入死循環(huán)，會(huì)導(dǎo)致整個(gè)系統(tǒng)通信模塊不可用，不能接收和處理外部消息，造成節(jié)點(diǎn)故障。

使用場(chǎng)景：客戶端的數(shù)量有限，業(yè)務(wù)處理非?？焖?，比如 Redis，業(yè)務(wù)處理的時(shí)間復(fù)雜度 O(1)。

單 Reactor 多線程

方案說(shuō)明：

Reactor 對(duì)象通過(guò) Select 監(jiān)控客戶端請(qǐng)求事件，收到事件后通過(guò) Dispatch 進(jìn)行分發(fā)。
如果是建立連接請(qǐng)求事件，則由 Acceptor 通過(guò) Accept 處理連接請(qǐng)求，然后創(chuàng)建一個(gè) Handler 對(duì)象處理連接完成后續(xù)的各種事件。
如果不是建立連接事件，則 Reactor 會(huì)分發(fā)調(diào)用連接對(duì)應(yīng)的 Handler 來(lái)響應(yīng)。
Handler 只負(fù)責(zé)響應(yīng)事件，不做具體業(yè)務(wù)處理，通過(guò) Read 讀取數(shù)據(jù)后，會(huì)分發(fā)給后面的 Worker 線程池進(jìn)行業(yè)務(wù)處理。
Worker 線程池會(huì)分配獨(dú)立的線程完成真正的業(yè)務(wù)處理，如何將響應(yīng)結(jié)果發(fā)給 Handler 進(jìn)行處理。
Handler 收到響應(yīng)結(jié)果后通過(guò) Send 將響應(yīng)結(jié)果返回給 Client。

優(yōu)點(diǎn)：可以充分利用多核 CPU 的處理能力。

缺點(diǎn)：多線程數(shù)據(jù)共享和訪問(wèn)比較復(fù)雜；Reactor 承擔(dān)所有事件的監(jiān)聽(tīng)和響應(yīng)，在單線程中運(yùn)行，高并發(fā)場(chǎng)景下容易成為性能瓶頸。

主從 Reactor 多線程

針對(duì)單 Reactor 多線程模型中，Reactor 在單線程中運(yùn)行，高并發(fā)場(chǎng)景下容易成為性能瓶頸，可以讓 Reactor 在多線程中運(yùn)行。

方案說(shuō)明：

Reactor 主線程 MainReactor 對(duì)象通過(guò) Select 監(jiān)控建立連接事件，收到事件后通過(guò) Acceptor 接收，處理建立連接事件。
Acceptor 處理建立連接事件后，MainReactor 將連接分配 Reactor 子線程給 SubReactor 進(jìn)行處理。
SubReactor 將連接加入連接隊(duì)列進(jìn)行監(jiān)聽(tīng)，并創(chuàng)建一個(gè) Handler 用于處理各種連接事件。
當(dāng)有新的事件發(fā)生時(shí)，SubReactor 會(huì)調(diào)用連接對(duì)應(yīng)的 Handler 進(jìn)行響應(yīng)。
Handler 通過(guò) Read 讀取數(shù)據(jù)后，會(huì)分發(fā)給后面的 Worker 線程池進(jìn)行業(yè)務(wù)處理。
Worker 線程池會(huì)分配獨(dú)立的線程完成真正的業(yè)務(wù)處理，如何將響應(yīng)結(jié)果發(fā)給 Handler 進(jìn)行處理。
Handler 收到響應(yīng)結(jié)果后通過(guò) Send 將響應(yīng)結(jié)果返回給 Client。

優(yōu)點(diǎn)：父線程與子線程的數(shù)據(jù)交互簡(jiǎn)單職責(zé)明確，父線程只需要接收新連接，子線程完成后續(xù)的業(yè)務(wù)處理。

父線程與子線程的數(shù)據(jù)交互簡(jiǎn)單，Reactor 主線程只需要把新連接傳給子線程，子線程無(wú)需返回?cái)?shù)據(jù)。

這種模型在許多項(xiàng)目中廣泛使用，包括 Nginx 主從 Reactor 多進(jìn)程模型，Memcached 主從多線程，Netty 主從多線程模型的支持。

3 種模式可以用個(gè)比喻來(lái)理解：餐廳常常雇傭接待員負(fù)責(zé)迎接顧客，當(dāng)顧客入坐后，侍應(yīng)生專門為這張桌子服務(wù)。

單 Reactor 單線程，接待員和侍應(yīng)生是同一個(gè)人，全程為顧客服務(wù)。
單 Reactor 多線程，1 個(gè)接待員，多個(gè)侍應(yīng)生，接待員只負(fù)責(zé)接待。
主從 Reactor 多線程，多個(gè)接待員，多個(gè)侍應(yīng)生。

Reactor 模式具有如下的優(yōu)點(diǎn)：

響應(yīng)快，不必為單個(gè)同步時(shí)間所阻塞，雖然 Reactor 本身依然是同步的。
編程相對(duì)簡(jiǎn)單，可以***程度的避免復(fù)雜的多線程及同步問(wèn)題，并且避免了多線程/進(jìn)程的切換開(kāi)銷。
可擴(kuò)展性，可以方便的通過(guò)增加 Reactor 實(shí)例個(gè)數(shù)來(lái)充分利用 CPU 資源。
可復(fù)用性，Reactor 模型本身與具體事件處理邏輯無(wú)關(guān)，具有很高的復(fù)用性。

Proactor 模型

在 Reactor 模式中，Reactor 等待某個(gè)事件或者可應(yīng)用或者操作的狀態(tài)發(fā)生（比如文件描述符可讀寫，或者是 Socket 可讀寫）。

然后把這個(gè)事件傳給事先注冊(cè)的 Handler（事件處理函數(shù)或者回調(diào)函數(shù)），由后者來(lái)做實(shí)際的讀寫操作。

其中的讀寫操作都需要應(yīng)用程序同步操作，所以 Reactor 是非阻塞同步網(wǎng)絡(luò)模型。

如果把 I/O 操作改為異步，即交給操作系統(tǒng)來(lái)完成就能進(jìn)一步提升性能，這就是異步網(wǎng)絡(luò)模型 Proactor。

Proactor 是和異步 I/O 相關(guān)的，詳細(xì)方案如下：

Proactor Initiator 創(chuàng)建 Proactor 和 Handler 對(duì)象，并將 Proactor 和 Handler 都通過(guò) AsyOptProcessor（Asynchronous Operation Processor）注冊(cè)到內(nèi)核。
AsyOptProcessor 處理注冊(cè)請(qǐng)求，并處理 I/O 操作。
AsyOptProcessor 完成 I/O 操作后通知 Proactor。
Proactor 根據(jù)不同的事件類型回調(diào)不同的 Handler 進(jìn)行業(yè)務(wù)處理。
Handler 完成業(yè)務(wù)處理。

可以看出 Proactor 和 Reactor 的區(qū)別：

Reactor 是在事件發(fā)生時(shí)就通知事先注冊(cè)的事件（讀寫在應(yīng)用程序線程中處理完成）。
Proactor 是在事件發(fā)生時(shí)基于異步 I/O 完成讀寫操作（由內(nèi)核完成），待 I/O 操作完成后才回調(diào)應(yīng)用程序的處理器來(lái)進(jìn)行業(yè)務(wù)處理。

理論上 Proactor 比 Reactor 效率更高，異步 I/O 更加充分發(fā)揮 DMA(Direct Memory Access，直接內(nèi)存存取)的優(yōu)勢(shì)，但是有如下缺點(diǎn)：

編程復(fù)雜性，由于異步操作流程的事件的初始化和事件完成在時(shí)間和空間上都是相互分離的，因此開(kāi)發(fā)異步應(yīng)用程序更加復(fù)雜。應(yīng)用程序還可能因?yàn)榉聪虻牧骺囟兊酶与y以 Debug。
內(nèi)存使用，緩沖區(qū)在讀或?qū)懖僮鞯臅r(shí)間段內(nèi)必須保持住，可能造成持續(xù)的不確定性，并且每個(gè)并發(fā)操作都要求有獨(dú)立的緩存，相比 Reactor 模式，在 Socket 已經(jīng)準(zhǔn)備好讀或?qū)懬?，是不要求開(kāi)辟緩存的。
操作系統(tǒng)支持，Windows 下通過(guò) IOCP 實(shí)現(xiàn)了真正的異步 I/O，而在 Linux 系統(tǒng)下，Linux 2.6 才引入，目前異步 I/O 還不完善。

因此在 Linux 下實(shí)現(xiàn)高并發(fā)網(wǎng)絡(luò)編程都是以 Reactor 模型為主。

參考文章：

從 0 開(kāi)始學(xué)架構(gòu) —— Alibaba 技術(shù)專家李運(yùn)華
技術(shù)：Linux 網(wǎng)絡(luò) IO 模型
多線程網(wǎng)絡(luò)服務(wù)模型
IO 中的阻塞、非阻塞、同步、異步
UNIX 網(wǎng)絡(luò)編程卷 1：套接字聯(lián)網(wǎng) API（第 3 版）
異步網(wǎng)絡(luò)模型

陳彩華(caison)，主要從事服務(wù)端開(kāi)發(fā)、需求分析、系統(tǒng)設(shè)計(jì)、優(yōu)化重構(gòu)工作，主要開(kāi)發(fā)語(yǔ)言是 Java，現(xiàn)任廣州貝聊服務(wù)端研發(fā)工程師。微信號(hào)：hua1881375。

【原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為.com】

網(wǎng)頁(yè)名稱：如何理解高性能網(wǎng)絡(luò)模型？這篇文章說(shuō)透了
文章分享：http://m.fisionsoft.com.cn/article/cojhceg.html

新聞中心

其他資訊