一般來說，網(wǎng)絡(luò)應(yīng)用系統(tǒng)服務(wù)器的實(shí)現(xiàn)，我們從設(shè)計(jì)模式的角度看，有兩種設(shè)計(jì)方案可供選擇：
Reactor服務(wù)器，或者Proactor服務(wù)器。無論是Reactor，或者Proactor, 都是基于事件驅(qū)動的架構(gòu)設(shè)計(jì)(Event-driven architecture), 它們的核心是思想是：分離網(wǎng)絡(luò)事件的監(jiān)視，驅(qū)動與事物本身的邏輯處理。我們能看到的是：對任何的網(wǎng)絡(luò)應(yīng)用而言，其對網(wǎng)絡(luò)事件的監(jiān)視，處理往往是大同小異的，是可以分離出來作為可復(fù)用組件而存在的。
對所有這些網(wǎng)絡(luò)應(yīng)用，所不用的是對網(wǎng)絡(luò)請求的邏輯處理。不同于Proactor， 或者Reactor，一般的設(shè)計(jì)方法是：
 

而Proactor， 或者Reactor,設(shè)計(jì)的精髓是:

別看這一點(diǎn)小小的變化，這是所謂的Hollywood Principle: 'Don't call us, we'll call you'。這是Framework設(shè)計(jì)者慣用的設(shè)計(jì)技巧，依賴倒轉(zhuǎn)（The Dependency-Inversion Principle）：
a. 高層模塊不應(yīng)該依賴于低層模塊，應(yīng)當(dāng)依賴于抽象。
b. 抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)依賴于抽象。
言歸正傳,我們來具體談?wù)凴eatctor and Proactor.
一 、Reactor服務(wù)器實(shí)現(xiàn)。
在Reactor的實(shí)現(xiàn)可分為兩層：
a.Demultiplexing/Dispatching層：獨(dú)立于應(yīng)用邏輯層，捕獲，分發(fā)網(wǎng)絡(luò)請求給具體的網(wǎng)絡(luò)請求處理器。
在這里注意的是，Demultiplexing和Dispatching是兩個(gè)不同的概念，Demultiplexing指的是網(wǎng)絡(luò)請求的偵聽，及其偵聽以后尋找適合的處理器。Dispatching指的是對處理器的回調(diào)。
b.應(yīng)用邏輯層組件：主要處理與應(yīng)用相關(guān)的事物處理。
其基本的結(jié)構(gòu)圖為

其各個(gè)組成模塊的功能為：

--〉句柄: 調(diào)用操作系統(tǒng)API獲得，用于identify事件源，如：網(wǎng)絡(luò)連接，打開的文件。
--〉同步事件分離器:操作系統(tǒng)功能,通過API提供,典型的如: select調(diào)用，如windows平臺上的WaitForMultileObj
--〉事件處理器：這是Demultiplexing/Dispatching層定義的抽象借口，是Demultiplexing/Dispatching層與應(yīng)用邏輯層之間的協(xié)議約定。應(yīng)用邏輯層依賴于該抽象借口。
--〉具體事件處理器：事件處理器的具體實(shí)現(xiàn)，一般來說，由應(yīng)用邏輯層組件實(shí)現(xiàn)。
--〉Reactor：提供接口給應(yīng)用邏輯層，注冊或者反注冊事件處理器，運(yùn)行應(yīng)用的事件循環(huán)（反復(fù)調(diào)用同步事件分離器），驅(qū)動Demultiplexing/Dispatching層。

二 、Proactor服務(wù)器實(shí)現(xiàn)。
在Proactor的實(shí)現(xiàn)也分為兩層：
a.Demultiplexing/Dispatching層：獨(dú)立于應(yīng)用邏輯層，捕獲，分發(fā)網(wǎng)絡(luò)請求給具體的網(wǎng)絡(luò)請求處理器,不同于Reactor的是,這一層的策略處理
基于異步操作,從實(shí)現(xiàn)的復(fù)雜度上,要復(fù)雜于Reactor。
b.應(yīng)用邏輯層組件：主要處理與應(yīng)用相關(guān)的事物處理。
Proactor基本的結(jié)構(gòu)圖為

--〉句柄: 調(diào)用操作系統(tǒng)API獲得，用于identify事件源，如：網(wǎng)絡(luò)連接，打開的文件。與Reactor不同的是,由于Proactor操作是異步的，所以，與每一個(gè)異步IO操作項(xiàng)關(guān)聯(lián)的，有一個(gè)完成事件(Completion Event)，當(dāng)一個(gè)異步的IO操作執(zhí)行完成后，一個(gè)操作系統(tǒng)的IO子系統(tǒng)會產(chǎn)生一個(gè)完成事件。
--〉異步操作：一個(gè)異步操作可以是一個(gè)服務(wù)請求的具體實(shí)現(xiàn)，如從連接的socket上讀入數(shù)據(jù)，或者寫入數(shù)據(jù)到本地磁盤。異步操作的發(fā)起執(zhí)行，并不會由于慢速的IO而阻塞調(diào)用線程，調(diào)用線程在發(fā)起異步操作之后，可以去做別的事情。這是Proactor能增大服務(wù)器處理吞吐量的關(guān)鍵所在。我們付出的代價(jià)是，開發(fā)的復(fù)雜度要比Reactor。
--〉完成 事件處理器：Demultiplexing/Dispatching層定義的抽象借口。由應(yīng)用邏輯層組件繼承來實(shí)現(xiàn)這些接口
函數(shù)。
--〉具體完成事件處理器：事件處理器的具體實(shí)現(xiàn)。
--〉異步操作處理器：由native的操作系統(tǒng)實(shí)現(xiàn)。當(dāng)一個(gè)異步操作完成執(zhí)行時(shí)，異步操作處理器會產(chǎn)生一個(gè)完成事件，然后把這個(gè)完成事件插入到完成事件隊(duì)列。
--〉完成事件隊(duì)列：用于保存異步操作完成事件的隊(duì)列。在windows平臺上，就是我們所說的完成端口。
--〉異步事件分離器: 操作系統(tǒng)功能,通過API提供。在windows平臺上，就是GetQueuedCompletionStatus()。異步事件分離器等待在完成事件隊(duì)列上，當(dāng)有完成事件被插入到完成事件隊(duì)列，異步事件分離器會從完成事件隊(duì)列取出該完成事件，返回給調(diào)用者。
--〉Proactor：運(yùn)行應(yīng)用的事件循環(huán)（反復(fù)調(diào)用異步操作處理器），驅(qū)動Demultiplexing/Dispatching層。
--〉發(fā)起者：用于發(fā)起異步IO操作。
三 、選擇？是Reactor,還是Proactor。
在我們實(shí)現(xiàn)我們的服務(wù)器，是選擇Reactor，還是Proactor，個(gè)人認(rèn)為需要考慮的因素是：
1）對于Reactor而言，好的地方是開發(fā)的復(fù)雜度小于Proactor，但缺點(diǎn)同樣明顯：
第一，基于Reactor實(shí)現(xiàn)的服務(wù)器可擴(kuò)展性不如Proactor，這是由其本質(zhì)決定的。在wiondows平臺上，無論是
Select,或者是WaitForMultiObj,其等待的最大handle數(shù)有一個(gè)最大的上限值（默認(rèn)值是64）。
第二，基于Reactor實(shí)現(xiàn)的服務(wù)器服務(wù)請求處理的吞吐量不如Proactor好。特別是當(dāng)對客戶端的請求處理需要更長的時(shí)間時(shí)，在Reactor的Demultiplexing/Dispatching層，由于Demultiplexing和Dispatching被順序化處理，這樣的話，很容易成為服務(wù)器性能的瓶頸。
2）對于Proactor，如果你需要一個(gè)高性能的，高吞吐量的，并發(fā)服務(wù)器，Proactor絕對是首選的解決方案，它的問題主要在開發(fā)的難度比較大。
不過，總的來說，我們可以看到，基于模式設(shè)計(jì)的Reactor和Proactor,都很好地把Application-Specific的處理邏輯從網(wǎng)絡(luò)，IO事件的Demultiplexing/Dispatching中分離出來，對應(yīng)用程序而言，由于這樣的松耦合關(guān)系，我們的應(yīng)用完全可以在Reactor和Proactor中自由切換，而不需要修改任何的代碼。、
四 、后記。
ACE Framework，對Reactor和Proactor設(shè)計(jì)模式給出了經(jīng)典的實(shí)現(xiàn)。請參考：
http://www.cs.wustl.edu/~schmidt/
個(gè)人覺得是很好的學(xué)習(xí)材料。