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