本文轉載自：http://www.cnblogs.com/hzbook/archive/2012/07/19/2599698.html

Reactor框架是ACE各個框架中最基礎的一個框架，其他框架都或多或少地用到了Reactor框架。本文分析Reactor構架模式的基本原理。

2.1  Reactor構架模式

對每一個構架模式的分析，我們都使用參考文獻的分析風格，著重分析意圖、上下文、問題、解決方案、結構和實現 6個方面的內容。而實現就是ACE原始碼。

1. 意圖

在事件驅動的應用中，將一個或多個客戶的服務請求分離（demultiplex）和排程（dispatch）給應用程式。

2. 上下文

在事件驅動的應用中，同步地、有序地處理同時接收的多個服務請求。

3. 問題

在分散式系統尤其是伺服器這一類事件驅動應用中，雖然這些請求最終會被序列化地處理，但是必須時刻準備著處理多個同時到來的服務請求。在實際應用 中，這些請求總是通過一個事件（如CONNECTOR、READ、WRITE等）來表示的。在有序地處理這些服務請求之前，應用程式必須先分離和排程這些 同時到達的事件。為了有效地解決這個問題，我們需要做到以下4方面：

• 為了提高系統的可測量性和反應時間，應用程式不能長時間阻塞在某個事件源上而停止對其他事件的處理，這樣會嚴重降低對客戶端的響應度。
• 為了提高吞吐量，任何沒有必要的上下文切換、同步和CPU之間的資料移動都要避免。
• 引進新的服務或改良已有的服務都要對既有的事件分離和排程機制帶來儘可能小的影響。
• 大量的應用程式程式碼需要隱藏在複雜的多執行緒和同步機制之後。

4. 解決方案

在一個或多個事件源上等待事件的到來，例如，一個已經連線的Socket描述符就是一個事件源。將事件的分離和排程整合到處理它的服務中，而將分離和排程機制從應用程式對特定事件的處理中分離開，也就是說分離和排程機制與特定的應用程式無關。

具體來說，每個應用程式提供的每個服務都有一個獨立的事件處理器與之對應。由事件處理器處理來自事件源的特定型別的事件。每個事件處理器都事先註冊 到Reactor管理器中。Reactor管理器使用同步事件分離器在一個或多個事件源中等待事件的發生。當事件發生後，同步事件分離器通知 Reactor管理器，最後由Reactor管理器排程和該事件相關的事件處理器來完成請求的服務。

5. 結構

在Reactor模式中，有5個關鍵的參與者。

• 描述符（handle）：由作業系統提供，用於識別每一個事件，如Socket描述符、檔案描述符等。在Linux中，它用一個整數來表示。事件可以來自外部，如來自客戶端的連線請求、資料等。事件也可以來自內部，如定時器事件。
• 同步事件分離器（demultiplexer）：是一個函式，用來等待一個或多個事件的發生。呼叫者會被阻塞，直到分離器分離的描述符集上有事件發生。Linux的select函式是一個經常被使用的分離器。
• 事件處理器介面（event handler）：是由一個或多個模板函式組成的介面。這些模板函式描述了和應用程式相關的對某個事件的操作。
• 具體的事件處理器：是事件處理器介面的實現。它實現了應用程式提供的某個服務。每個具體的事件處理器總和一個描述符相關。它使用描述符來識別事件、識別應用程式提供的服務。
• Reactor 管理器（reactor）：定義了一些介面，用於應用程式控制事件排程，以及應用程式註冊、刪除事件處理器和相關的描述符。它是事件處理器的排程核心。 Reactor管理器使用同步事件分離器來等待事件的發生。一旦事件發生，Reactor管理器先是分離每個事件，然後排程事件處理器，最後呼叫相關的模 板函式來處理這個事件。

通過上述分析，我們注意到，是Reactor管理器而不是應用程式負責等待事件、分離事件和排程事件。實際上，Reactor管理器並沒有被具體的 事件處理器呼叫，而是管理器排程具體的事件處理器，由事件處理器對發生的事件做出處理。這就是類似Hollywood原則的“反向控制”。應用程式要做的 僅僅是實現一個具體的事件處理器，然後把它註冊到Reactor管理器中。接下來的工作由管理器來完成。這些參與者的相互關係如圖2-1所示。

現在結合第1章分析的框架五元素來看一下Reactor構架模式的參與者與框架五元素之間的關係：Reactor構架模式的具體實現對應了元素1； 事件處理器介面對應元素2；具體的事件處理器對應元素3；Reactor管理器使用了Hollywood原則，可以認為和元素5對應；元素4的功能相對不 明顯，沒有明確的對應關係。

如果還是沒有理解Reactor構架模式，沒有關係，原始碼會說明所有問題。此時可再分析一遍Reactor構架模式，然後繼續以下內容。

2.2  Reactor框架結構

Reactor包含如下角色：

• Handle 控制代碼；用來標識socket連線或是開啟檔案；
• Synchronous Event Demultiplexer：同步事件多路分解器：由作業系統核心實現的一個函式；用於阻塞等待發生在控制代碼集合上的一個或多個事件；（如select/epoll；）
• Event Handler：事件處理介面
• Concrete Event HandlerA：實現應用程式所提供的特定事件處理邏輯；
• Reactor：反應器，定義一個介面，實現以下功能：
  1）供應用程式註冊和刪除關注的事件控制代碼；
  2）執行事件迴圈；
  3）有就緒事件到來時，分發事件到之前註冊的回撥函式上處理；

“反應”器名字中”反應“的由來：

“反應”即“倒置”，“控制逆轉”

具體事件處理程式不呼叫反應器，而是由反應器分配一個具體事件處理程式，具體事件處理程式對某個指定的事件發生做出反應；這種控制逆轉又稱為“好萊塢法則”（不要呼叫我，讓我來呼叫你）

3.1  Reactor框架概述

從對Reactor構架模式的分析中我們可以看出，要設計和實現一個簡單Reactor框架以支援I/O事件，需要實現兩個元件：事件處理器介面和Reactor管理器。至於其他元件，如同步事件分離器可以使用作業系統提供的select、poll或其他類似的函式；而描述符可以使用檔案描述符或其他可以識別事件的資料結構，一般作業系統都會提供。事件處理器介面包含一系列模板函式，可以根據實際處理的資料進行設計；Reactor管理器肩負著事件的分離和排程，是整個框架設計的核心。

ACE的Reactor框架在Linux平臺下使用檔案描述符作為I/O事件的描述符，使用ACE_Event_Handler類作為各類事件的處理器介面。將同步事件分離函式放到Reactor管理器中，這樣使用不同的同步事件分離函式就需要實現不同的Reactor管理器。ACE使用Bridge設計模式解決了這一問題，將與同步事件分離函式相關的操作放到Bridge設計模式的Implementor中。凡是ACE支援的同步事件分離函式都會有一個具體的Implementor與之對應。

ACE的Reactor管理器還提供了用於實現Singleton設計模式的操作，使用這些操作時，一個程序只能有一個全域性的Reactor管理器。在呼叫Singleton設計模式介面時，Reactor管理器會在啟動時根據作業系統的配置選擇一個具體的Implementor。當然，如果你不喜歡這個預設的Implementor，可以通過函式進行更換。為了提高整個系統對事件分離和排程的效能，ACE還允許應用程式建立多個Reactor管理器例項。在這種情況下，應用程式將不能呼叫用於Singleton設計模式的操作，只能直接使用Reactor管理器例項物件的方法實現對事件的分離和排程。同時提供這兩種使用方法，可以最大程度地滿足應用程式的苛刻要求。

ACE實現的Reactor框架結構要比Reactor構架模式中分析的結構複雜得多。這是因為ACE的Reactor框架除了處理I/O事件之外，還要處理定時器、訊號量等常見的事件，並且所有的這些處理都必須滿足跨平臺的要求。要將對這些事件的處理抽象出來，並且提供給應用程式一個統一的介面，ACE的Reactor管理器的實現還採用了Facade設計模式。實際上，Reactor框架管理的I/O事件、訊號量事件、定時器事件和Notify事件在實現上都有一個小的元件與之對應，這樣可以將Reactor管理器與具體的事件處理解耦。使用Facade設計模式，將這些小的元件的介面封裝起來，使得應用程式無法感知它們的存在，可以減少應用程式處理物件的數目，並且使得這些小的元件使用起來更加方便。

以上分析的3種設計模式以及Factory設計模式，在ACE的框架管理器的實現中被頻繁使用。這些設計模式以及它們的使用，既為我們學習設計模式提供了非常好的場景，又為我們實現軟體框架管理器提供了實用的方法。ACE的Reactor框架與框架五元素的對應關係非常密切，是一個典型的事件驅動型框架，它為我們打開了ACE的框架之門，是學習其他框架的基礎。

在深入到框架程式碼之前，我們先來看一個Reactor框架的使用示例，示例雖然簡單，但卻提供了一個實實在在的應用程式，也為我們的分析提供了一些思路。

3.2  Reactor框架應用示例

在本示例中我們用Reactor框架實現一個簡單的伺服器程式。這個伺服器程式等待客戶的連線請求，一旦請求到來，Socket連線建立後，伺服器程式簡單地列印客戶端的地址資訊和接收的資料，最後將新建的Socket關閉。

示例中的伺服器端程式需要處理兩類事件：Socket連線事件和通常的I/O事件。Socket連線事件用於接收客戶端的連線請求，I/O事件用於接收客戶端傳送的資料。這兩類事件是完全不同的，它們的檔案描述符也不一樣。與這兩類事件相對應，應用程式需要實現兩個具體的事件處理器。一個用於處理客戶端的連線，一個用於處理客戶端的資料。在示例中，這兩個具體的事件處理器分別為Acceptor類和Handle_data類，其中Acceptor類用於處理客戶端的連線，Handle_data類用於處理客戶端的資料。