反應器模式

反應器模式（Reactor pattern）是一種為處理服務請求並發提交到一個或者多個服務處理程序的事件設計模式。當請求抵達後，服務處理程序使用解多路分配策略，然後同步地派發這些請求至相關的請求處理程序。 ^[1]

結構

反應式應用的UML 2構件圖。典型的由2個子系統組成的反應器。把柄（又名套接字）和解多路復用器（比如select或epoll）典型的由作業系統來提供。反應式應用將提供分派器（事件循環）來通過調用事件處理器而反應於把柄事件，事件處理器被註冊為回調^[2]。

反應式伺服器的UML 2序列圖。在開始事件循環之前，反應式應用典型的為諸特定請求註冊把柄和事件處理器。事件循環響應基於請求的事件，通過調用事件處理器，傳遞把柄用於處理^[2]。

反應式應用由多個活動部份組成並依賴於一些支持機制^[2]：

把柄（Handle）

具有IO和數據的針對特定請求的一個標識符和接口。這通常採用套接字、文件描述符或類似機制的形式，它們應當由大多數現代的作業系統提供。

解多路復用器（Demultiplexer）

可以有效的監視一個把柄的狀態的事件通知器（notifier），它將有關的狀態變更通知給其他子系統，典型的是一個IO把柄成為了「準備好讀取」。傳統上這個角色由select()系統調用充任，而更加現今的例子包括epoll、kqueue和IOCP。

分派器（Dispatcher）

反應式應用的實際事件循環，這個構件維護着有效的事件處理器（handler）的註冊，它在一個事件被引發之時激發（invoke）適合的處理器。

事件處理器（Event Handler）

也叫做請求處理器，它是用來處理一種類型的服務請求的特定邏輯。反應器模式為了更大的靈活性而提倡將它們動態的向分派器註冊為回調。缺省情況下，反應器不使用多線程，轉而在跟分派器同一個線程中激發一個請求處理器。

事件處理器接口

抽象接口類，代表了事件處理器的通用屬性和方法。每個特定處理器都必須實現這個接口，分派器將通過這個接口來操作事件處理器。

應用

反應器模式及其變體已經用於很多web伺服器、應用伺服器和網絡編程框架：

• 自適配通信環境（ACE）^[2]
• 事件機器（英語：EventMachine）
• Netty^[3]
• Nginx^[4]
• Node.js^[5][6]
• Perl Object Environment
• POCO C++ Libraries（英語：POCO C++ Libraries）^[7]
• Spring Framework（版本5之後）^[8]
• Tokio（英語：Tokio (software)）
• Twisted^[9]
• Vert.x^[3]

屬性

所有的反應器系統在定義上是單線程的，但可以在多線程環境中存在。

優點

反應器模式可完全分離程序特定代碼，這意味着應用可分為模塊化的，可復用的組件。另外，由於請求的處理程序是同步調用，反應器模式可允許簡單粗粒並發而不必添加多線程並發系統的複雜性。

限制

由於反向的流程控制，反應器模式比過程模式更難以調試 ^[2]。此外，因為請求處理器只會被同步調用，因此會限制反應器模式的最大並發數，特別是在對稱多處理硬件。反應器模式的可擴展性，不僅受限於請求處理器的同步調用，同時也受解多路器限制。^[10]

參見

• 廣播反應器模式（英語：Proactor pattern） （該模式也會解多路復用和分派事件，但它是異步的）
• C10K問題（英語：C10k problem）
• 事件驅動編程
• libuv
• 反應式編程
• 主動對象（英語：Active object）
• 觀察者模式