libevent源碼分析(二) Reactor模式

由於$libevent$本身就是一個$Reactor$，所以瞭解$Reactor$這樣一個應用於服務端的開發設計模式很有必要。

1.$Reactor$模式

藉由$Wikipedia$上的解釋：

"The reactor design pattern is an event handling pattern for handling service requests delivered concurrently by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to associated request handlers."

從這個描述中我們能瞭解到$Reactor$模式是事件驅動的，有一個或多個併發輸入源，有一個 $Service$ $Handler$，有多個 $Request$ $Handler$；這個$Service$ $Handler$會同步的將輸入的請求（$Event$）多路複用的分發給相應的$Request$ $Handler$。

2.$Reactor$模式的事件處理機制

不同於普通的函數調用，應用程序不是主動的調用某個$API$完成處理，恰恰相反；$Reactor$ 逆置了事件處理流程，應用程序需要提供相應的接口並註冊到 $Reactor$ 上，如果相應的事件發生，$Reactor$ 將主動調用應用程序註冊的接口，這些接口又稱爲$Callback$函數(回調函數)。使用 $libevent$ 也是想 $libevent$ 框架註冊相應的事件和回調函數；當這些事件發生時，$libevent$ 會調用這些回調函數處理相應的事件（$I/O$ 讀寫、定時和信號）。

3.$Reactor$模式具備的優點
$Reactor$ 模式是編寫高性能網絡服務器的必備技術之一，它具有如下的優點：

• 1）響應快，不必爲單個同步時間所阻塞，雖然 $Reactor$ 本身依然是同步的；
• 2）編程相對簡單，可以最大程度的避免複雜的多線程及同步問題，並且避免了多線程/
  進程的切換開銷；
• 3）可擴展性，可以方便的通過增加 $Reactor$ 實例個數來充分利用 $CPU$ 資源；
• 4）可複用性，$reactor$ 框架本身與具體事件處理邏輯無關，具有很高的複用性；

4.$Reactor$模式框架

使用$Reactor$模型必備的幾個組件：事件源、$Reactor$框架、多路複用機制以及事件處理機制，如下圖：

(一)事件源
$Linux$ 上是文件描述符，$Windows$ 上就是 $Socket$ 或者 $Handle$ 了，這裏統一稱爲“句柄 集”；程序在指定的句柄上註冊關心的事件，比如 $I/O$ 事件。

(二)$event$ $demultiplexer$——事件多路分發機制
由操作系統提供的$I/0$多路複用機制，比如$select$、$poll以及epoll$。

• 1.首先，程序將其關心的$event$註冊到$event$ $demultiplexer$；
• 2.當有事件到達時，$event$ $demultiplexer$會發出一個通知，告訴$Handle$在已註冊的$event$中，有一個或多個$event$準備就緒；
• 3.程序收到通知後，以非阻塞的方式對事件進行處理

對應到 $libevent$ 中，依然是 $select$、$poll$、$epoll$ 等，但是 $libevent$ 使用結構體 $eventop$ 進行了封裝，以統一的接口來支持這些 $I/O$ 多路複用機制，達到了對外隱藏底層系統機制的目的。

(三)$Reactor$–反應器
$Reactor$,事件處理的接口。內部使用$event$ $demultiplexer$進行註冊、註銷事件；並運行事件循環；當有事件準備就緒，調用註冊事件的回調函數處理事件。

對應到$libevent$，就是$event$_ $base$結構體。

常用的$Reactor$聲明：

class Reactor {
public:
	int register_handler(Event_Handler *pHandler, int event); 
	int remove_handler(Event_Handler *pHandler, int event); 
	void handle_events(timeval *ptv); 
	// ... 
};

(四)$Event$ $Handle$—事件處理程序
事件處理程序提供了一組接口，分別對應於不同類型的事件；當有事件發生時，$Reactor$調用相應的事件處理函數，通常會綁定一個有效的句柄。

對應到$libevent$，就是$event$結構體。

常用的$Event$ $Handle$聲明：

class Event_Handle{
public:
	virtual void handle_read() = 0; 
	virtual void handle_write() = 0; 
	virtual void handle_timeout() = 0; 
	virtual void handle_close() = 0; 
	virtual HANDLE get_handle() = 0; 
	// ... 
};

class Event_Handle{
public:
	// events maybe read/write/timeout/close .etc 
	virtual void handle_events(int events) = 0; 
	virtual HANDLE get_handle() = 0; 
	// ... 
};

5.$Reactor$事件處理流程
如下圖：

6.與$Proactor$模式區別

• (1) $Reactor$模式是基於同步$I/O$的，而$Proactor$則是基於異步$I/O$；

• (2)上面我們提到$Reactor$模式是應用程序註冊事件到$Reactor$，然後當事件發生時，$Reactor$調用其回調函數進行事件處理，由回調函數來進行讀寫等操作；而在$Proactor$模式中，事件處理者直接發起一個異步讀寫操作(相當於請求)，而實際的工作由操作系統完成。

• (3)兩種模式的處理步驟
  標準的$Reactor$步驟：
  1）等待事件($Reactor$完成)
  2）將”就緒”事件發給事件註冊的事件處理者或者回調函數($Reactor$完成)
  3）讀數據(用戶完成)
  4）處理數據(用戶完成)
  模擬的$Proactor$步驟：
  1）等待事件($Proactor$完成)
  2）讀數據($Proactor$完成)
  3）把數據準備好的消息傳給事件處理者($Proactor$完成)
  4）處理數據(用戶完成)

• (4)兩者區別
  1.$Reactor$模式更多的是關心事件的發生，將如何處理事件的後續交給了用戶態的應用來處理；而$Proactor$則☞關心由操作系統完成異步非阻塞操作之後的結果
  2.$Proactor$場景中只能夠使用異步非阻塞的$syscall$(系統調用)，而$Reactor$的場景中更多地是使用非阻塞同步的$syscall$(系統調用)；

參考文章：關於Reactor和Proactor的區別
libevent源碼深度剖析二