一般來說，網(wǎng)絡(luò)應(yīng)用系統(tǒng)服務(wù)器的實現(xiàn)，我們從設(shè)計模式的角度看，有兩種設(shè)計方案可供選擇：
Reactor服務(wù)器，或者Proactor服務(wù)器。無論是Reactor，或者Proactor,
都是基于事件驅(qū)動的架構(gòu)設(shè)計(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è)計方法是：
而Proactor， 或者Reactor,設(shè)計的精髓是:
別看這一點小小的變化，這是所謂的Hollywood Principle: 'Don't call us, we'll call
you'。這是Framework設(shè)計者慣用的設(shè)計技巧，依賴倒轉(zhuǎn)（The Dependency-Inversion Principle）：
a.
高層模塊不應(yīng)該依賴于低層模塊，應(yīng)當依賴于抽象。
b. 抽象不應(yīng)該依賴于細節(jié)，細節(jié)依賴于抽象。
言歸正傳,我們來具體談?wù)凴eatctor and
Proactor.
一
、Reactor服務(wù)器實現(xiàn)。
在Reactor的實現(xiàn)可分為兩層：
a.Demultiplexing/Dispatching層：獨立于應(yīng)用邏輯層，捕獲，分發(fā)網(wǎng)絡(luò)請求給具體的網(wǎng)絡(luò)請求處理器。
在這里注意的是，Demultiplexing和Dispatching是兩個不同的概念，Demultiplexing指的是網(wǎng)絡(luò)請求的偵聽，及其偵聽以后尋找適合的處理器。Dispatching指的是對處理器的回調(diào)。
b.應(yīng)用邏輯層組件：主要處理與應(yīng)用相關(guān)的事物處理。
其基本的結(jié)構(gòu)圖為
其各個組成模塊的功能為：
--〉句柄:
調(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)用邏輯層依賴于該抽象借口。
--〉具體事件處理器：事件處理器的具體實現(xiàn)，一般來說，由應(yīng)用邏輯層組件實現(xiàn)。
--〉Reactor：提供接口給應(yīng)用邏輯層，注冊或者反注冊事件處理器，運行應(yīng)用的事件循環(huán)（反復(fù)調(diào)用同步事件分離器），驅(qū)動Demultiplexing/Dispatching層。
二
、Proactor服務(wù)器實現(xiàn)。
在Proactor的實現(xiàn)也分為兩層：
a.Demultiplexing/Dispatching層：獨立于應(yīng)用邏輯層，捕獲，分發(fā)網(wǎng)絡(luò)請求給具體的網(wǎng)絡(luò)請求處理器,不同于Reactor的是,這一層的策略處理
基于異步操作,從實現(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操作是異步的，所以，與每一個異步IO操作項關(guān)聯(lián)的，有一個完成事件(Completion
Event)，當一個異步的IO操作執(zhí)行完成后，一個操作系統(tǒng)的IO子系統(tǒng)會產(chǎn)生一個完成事件。
--〉異步操作：一個異步操作可以是一個服務(wù)請求的具體實現(xiàn)，如從連接的socket上讀入數(shù)據(jù)，或者寫入數(shù)據(jù)到本地磁盤。異步操作的發(fā)起執(zhí)行，并不會由于慢速的IO而阻塞調(diào)用線程，調(diào)用線程在發(fā)起異步操作之后，可以去做別的事情。這是Proactor能增大服務(wù)器處理吞吐量的關(guān)鍵所在。我們付出的代價是，開發(fā)的復(fù)雜度要比Reactor。
--〉完成
事件處理器：Demultiplexing/Dispatching層定義的抽象借口。由應(yīng)用邏輯層組件繼承來實現(xiàn)這些接口
函數(shù)。
--〉具體完成事件處理器：事件處理器的具體實現(xiàn)。
--〉異步操作處理器：由native的操作系統(tǒng)實現(xiàn)。當一個異步操作完成執(zhí)行時，異步操作處理器會產(chǎn)生一個完成事件，然后把這個完成事件插入到完成事件隊列。
--〉完成事件隊列：用于保存異步操作完成事件的隊列。在windows平臺上，就是我們所說的完成端口。
--〉異步事件分離器:
操作系統(tǒng)功能,通過API提供。在windows平臺上，就是GetQueuedCompletionStatus()。異步事件分離器等待在完成事件隊列上，當有完成事件被插入到完成事件隊列，異步事件分離器會從完成事件隊列取出該完成事件，返回給調(diào)用者。
--〉Proactor：運行應(yīng)用的事件循環(huán)（反復(fù)調(diào)用異步操作處理器），驅(qū)動Demultiplexing/Dispatching層。
--〉發(fā)起者：用于發(fā)起異步IO操作。
三
、選擇？是Reactor,還是Proactor。
在我們實現(xiàn)我們的服務(wù)器，是選擇Reactor，還是Proactor，個人認為需要考慮的因素是：
1）對于Reactor而言，好的地方是開發(fā)的復(fù)雜度小于Proactor，但缺點同樣明顯：
第一，基于Reactor實現(xiàn)的服務(wù)器可擴展性不如Proactor，這是由其本質(zhì)決定的。在wiondows平臺上，無論是
Select,或者是WaitForMultiObj,其等待的最大handle數(shù)有一個最大的上限值（默認值是64）。
第二，基于Reactor實現(xiàn)的服務(wù)器服務(wù)請求處理的吞吐量不如Proactor好。特別是當對客戶端的請求處理需要更長的時間時，在Reactor的Demultiplexing/Dispatching層，由于Demultiplexing和Dispatching被順序化處理，這樣的話，很容易成為服務(wù)器性能的瓶頸。
2）對于Proactor，如果你需要一個高性能的，高吞吐量的，并發(fā)服務(wù)器，Proactor絕對是首選的解決方案，它的問題主要在開發(fā)的難度比較大。
不過，總的來說，我們可以看到，基于模式設(shè)計的Reactor和Proactor,都很好地把Application-Specific的處理邏輯從網(wǎng)絡(luò)，IO事件的Demultiplexing/Dispatching中分離出來，對應(yīng)用程序而言，由于這樣的松耦合關(guān)系，我們的應(yīng)用完全可以在Reactor和Proactor中自由切換，而不需要修改任何的代碼。、
四
、后記。
ACE Framework，對Reactor和Proactor設(shè)計模式給出了經(jīng)典的實現(xiàn)。請參考：
http://www.cs.wustl.edu/~schmidt/
個人覺得是很好的學(xué)習(xí)材料。