1. libevent簡介
Libevent 有幾個顯著的亮點：
=> 事件驅動（event-driven），高性能;
=> 輕量級，專注於網絡，不如ACE那么臃腫龐大；
=> 源代碼相當精煉、易讀；
=> 跨平台，支持Windows、Linux、*BSD和Mac Os；
=> 支持多種I/O多路復用技術， epoll、poll、dev/poll、select和kqueue等；
=> 支持I/O，定時器和信號等事件；
=> 注冊事件優先級；
Libevent已經被廣泛的應用，作為底層的網絡庫；比如memcached、Vomit、Nylon、Netchat等等
2. Reactor的事件處理機制
Reactor釋義“反應堆”，是一種事件驅動機制。和普通函數調用的不同之處在於：應用程序不是主動的調用某個API完成處理，而是恰恰相反，Reactor逆置了事件處理流程，應用程序需要提供相應的接口並注冊到Reactor上，如果相應的時間發生，Reactor將主動調用應用程序注冊的接口，這些接口又稱為“回調函數”。使用Libevent也是想Libevent框架注冊相應的事件和回調函數；當這些時間發聲時，Libevent會調用這些回調函數處理相應的事件（I/O讀寫、定時和信號）。
用“好萊塢原則”來形容Reactor再合適不過了：不要打電話給我們，我們會打電話通知你。
舉個例子：你去應聘某xx公司，面試結束后。
“普通函數調用機制”公司HR比較懶，不會記你的聯系方式，那怎么辦呢，你只能面試完后自己打電話去問結果；有沒有被錄取啊，還是被據了；
3 . Reactor模式的優點
Reactor模式是編寫高性能網絡服務器的必備技術之一，它具有如下的優點
1）響應快，不必為單個同步時間所阻塞，雖然Reactor本身依然是同步的；
2）編程相對簡單，可以最大程度的避免復雜的多線程及同步問題，並且避免了多線程/進程的切換開銷；
3）可擴展性，可以方便的通過增加Reactor實例個數來充分利用CPU資源；
4）可復用性，reactor框架本身與具體事件處理邏輯無關，具有很高的復用性；
4. Reactor模式的缺點
1）相比傳統的模型，Reactor增加了一定的復雜性，因而具有一定的門檻，並且不易於調試。
2）Reactor模式需要底層的Synchronous Event Demultiplexer支持，比如Java中的Selector支持，操作系統的select系統調用支持。
3）Reactor模式在IO讀寫數據時會在同一線程中實現，即使使用多個Reactor機制的情況下，那些共享一個Reactor的Channel如果出現一個長時間的數據讀寫，會影響這 個 Reactor中其他Channel的相應時間。例如在大文件傳輸時，IO操作會影響其他客戶端的時間，因而對於這種操作，使用傳統的Thread-Per-Connection或許是一個更好的選擇，或者采用Proactor模式。
4. Reactor模式框架
使用Reactor模型，必備的幾個組件：事件源、Reactor框架、多路復用機制和事件處理程序，先來看看Reactor模型的整體框架，接下來再對每個組件做逐一說明。
1） 事件源
Linux上是文件描述符，Windows上就是Socket或者Handle了，這里統一稱為“句柄集”；程序在指定的句柄上注冊關心的事件，比如I/O事件。
2） event demultiplexer——事件多路分發機制
由操作系統提供的I/O多路復用機制，比如select和epoll。
程序首先將其關心的句柄（事件源）及其事件注冊到event demultiplexer上；
當有事件到達時，event demultiplexer會發出通知“在已經注冊的句柄集中，一個或多個句柄的事件已經就緒”；
程序收到通知后，就可以在非阻塞的情況下對事件進行處理了。
對應到libevent中，依然是select、poll、epoll等，但是libevent使用結構體eventop進行了封裝，以統一的接口來支持這些I/O多路復用機制，達到了對外隱藏底層系統機制的目的。
3） Reactor——反應器
Reactor，是事件管理的接口，內部使用event demultiplexer注冊、注銷事件；並運行事件循環，當有事件進入“就緒”狀態時，調用注冊事件的回調函數處理事件。
對應到libevent中，就是event_base結構體。
一個典型的Reactor聲明方式
5. Reactor事件處理流程
前面說過Reactor將事件流“逆置”了，那么使用Reactor模式后，事件控制流是什么樣子呢？
可以參見下面的序列圖。
