Reactor 和 Proactor 是基于事件驅動，在網絡編程中經常用到兩種設計模式。

曾經在一個項目中用到了網絡庫 libevent，也學習了一段時間，其內部實現所用到的就是 Reactor，所知道的還有 ACE；Proactor 模式的庫有 Boost.Asio，ACE，暫時沒有用過。但我也翻閱了一些文檔，理解了它的實現方法。下面是我在學習這兩種設計模式過程的筆記。

Reactor

Reactor，即反應堆。Reactor 的一般工作過程是首先在 Reactor?中注冊（Reactor）感興趣事件，并在注冊時候指定某個已定義的回調函數（callback）；當客戶端發送請求時，在 Reactor?中會觸發剛才注冊的事件，并調用對應的處理函數。在這一個處理回調函數中，一般會有數據接收、處理、回復請求等操作。

libevent 采用的就是 Reactor?的設計思想。其?Reactor?的中心思想是眾所周知的 I/O 多路復用：select,poll,epoll,kqueue 等.libevent 精彩的將定時事件，信號處理，I/O 事件結合在在一起，也就是說用戶同時在 Reactor?中注冊上述三類事件。遺憾的是，libevent 不支持多線程，也就是說它同步處理請求，導致不能處理大量的請求；這樣并不是說 Reactor?實現的網絡庫都不支持多線程，而是 libevent 本身的原因，我們也可以通過修改讓 ilbevent 支持多線程，并發處理多個請求。

下面是 libevent 的一段代碼，大概能夠說明 Reactor?工作模式：

/*accept callback function.*/ void accept_callback(int fd, ?????????????????????shortev,void *arg) { ????...... } ...... struct event accept_event; event_set(&accept_event, ????????socketlisten, ????????EV_READ|EV_PERSIST, ????????accept_callback, ????????NULL); event_add(&accept_event, ????????NULL); event_dispatch();

Proactor

從上面 Reactor?模式中，發現服務端數據的接收和發送都占用了用戶狀態（還有一種內核態），這樣服務器的處理操作就在數據的讀寫上阻塞花費了時間，節省這些時間的辦法是借助操作系統的異步讀寫；異步讀寫在調用的時候可以傳遞回調函數或者回送信號，當異步操作完畢，內核會自動調用回調函數或者發送信號。Proactor 就是這么做的，所以很依賴操作系統。來一幅 UML：

和時序圖：

注：這兩幅美艷的圖片來自?Proactor.doc，下面會提到.

Proactor?的實現主要有三個部分：異步操作處理器，Proactor 和 事件處理函數。其中：

- 異步操作處理器，很依賴操作系統的異步處理機制，如若操作系統沒有實現，我們可以自行模擬，即開專門的數據讀寫線程，數據讀寫完畢觸發相應的時間（如果有注冊的話）； - Proactor，會接收異步操作的提醒，調用相應的事件處理函數，它有自己的 event loop； - 事件處理函數，事件觸發，執行操作；

曾經看過 Proactor.doc，作者是 Douglas C.?Schmidt，你可以在這里閱讀此文檔。里面的關于 Proactor?的講解很精彩，部分摘抄和自己的理解如下：當連接 web 服務器時：

• web 服務器指定（1）接收器，此接收器相當于服務器的客戶端，它可以啟動異步的 accept 操作；
• 接收器調用操作系統上的異步接收操作（2），并傳遞自己和 Proactor?的引用；異步接收操作結束后，前者用作事件處理函數，后者會回過頭來分發事件；注：傳遞 Proactor?是為了讓操作系統通知正確的 Proactor，可能會存在多個 Proactor；傳遞接收器自己是為了在異步接收操作結束后 Proactor?能調用正確的事件處理函數，以下同理。
• web 服務器調用 Proactor?的事件循環；（3）
• web 瀏覽器連接 web 服務器；（4）
• 異步接收操作結束后，操作系統產生事件（通過回調或者信號）并通知 Proactor（5），Proactor 收到后會調用相應的事件處理函數，即交由接收器處理；（6）
• 接收器生成 HTTP 處理器，執行操作；（7）
• HTTP 處理器解析事件，啟動異步讀操作（8），獲取來自瀏覽器的 GET 請求。同樣，HTTP 處理器傳遞自己和 Proactor?的引用；
• web 服務器的控制權交還回 Proactor?的事件循環。（9）

接收 GET 請求過后，會處理數據：

• 瀏覽器發送（1）一個 HTTP GET 請求；
• 異步讀操作結束后，操作系統會通知 Proactor，Proactor 分發給事件處理函數；（2，3）
• 事件處理器解析請求。（4）2-4 步驟會重復，指導所有的數據都接收為止；
• 事件處理器產生答復數據；（5）
• HTTP 處理器啟動異步寫操作（6），傳輸應答數據，同樣的這里還會傳遞處理器自己和 Proactor；
• 異步寫操作結束，操作系統通知 Proactor（7），Proactor 分發給事件處理函數（8）。6-8 步驟會重復直到所有的數據寫完為止。至此，一個請求回復完成。

總結

相比網絡編程中最簡單的思路模式：bind,listen,accept,read,server operator,write，Reactor 和 Proactor 是兩種高性能的設計模式，掌握此兩種模式，有助于理解一些網絡庫的工作流程。此文提到了兩種設計模式，但沒有一些技術細節，譬如多線程同步。如果在 Reactor 中支持多線程，或多個線程共享一個 Proactor，線程的同步問題就來了。共享一篇印象筆記關于線程的綜合討論：這里.

《Comparing Two High-Performance I/O Design Patterns》提到一個將 Reactor 模擬 Proactor 而不借助操作系統異步機制的方法：同樣在 Reactor 注冊感興趣的事件（比如讀），當事件發生時，執行非阻塞的讀，讀畢即才調用數據處理——假異步。

最后，實踐出真知。歡迎討論。

參考：

- Proactor.pdf，http://www.laputan.org/pub/sag/proactor.pdf

- 《Comparing Two High-Performance I/O Design Patterns》，http://www.artima.com/articles/io_design_patterns.html

- 《libevent源碼深度剖析》，http://blog.csdn.net/sparkliang/article/details/4957667

- 《?IO - 同步，異步，阻塞，非阻塞 （亡羊補牢篇）》，http://blog.csdn.net/historyasamirror/article/details/5778378

搗亂 2013-08-21

總結

以上是生活随笔為你收集整理的两种高性能 I/O 设计模式 Reactor 和 Proactor的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。