學習libevent有助於提升程序設計功力，除了網絡程序設計方面外，libevent的代碼里有很多有用的設計技巧和基礎數據結構，比如信息隱藏、函數指針、c語言的多態支持、鏈表和堆等等，都有助於提升自身的程序功力。
程序設計不止要了解框架，很多細節之處恰恰也是事關整個系統成敗的關鍵。只對libevent本身的框架大概了解，那或許僅僅是一知半解，不深入代碼分析，就難以了解其設計的精巧之處，也就難以為自己所用。
事實上libevent本身就是一個典型的Reactor模型，理解Reactor模式是理解libevent的基石。因此本篇將介紹典型的事件驅動設計模式——Reactor模式，並列出libevnet中的幾個重要組件和Reactor的對應關系。
1 Reactor的事件處理機制
首先來回想一下普通函數調用的機制：程序調用某函數?函數執行，程序等待?函數將結果和控制權返回給程序?程序繼續處理。
Reactor釋義“反應堆”，是一種事件驅動機制。和普通函數調用的不同之處在於：應用程序不是主動的調用某個API完成處理，而是恰恰相反，Reactor逆置了事件處理流程，應用程序需要提供相應的接口並注冊到Reactor上，如果相應的事件發生，Reactor將主動調用應用程序注冊的接口，這些接口又稱為“回調函數”。使用libevent也就是向libevent框架注冊相應的事件和回調函數；當這些事件發聲時，libevent會調用這些回調函數處理相應的事件（I/O讀寫、定時和信號）。
用“好萊塢原則”來形容Reactor再合適不過了：不要打電話給我們，我們會打電話通知你。
舉個例子：你去應聘某xx公司，面試結束后。
“普通函數調用機制”公司HR比較懶，不會記你的聯系方式，那怎么辦呢，你只能面試完后自己打電話去問結果；有沒有被錄取啊，還是被據了；
“Reactor”公司HR就記下了你的聯系方式，結果出來后會主動打電話通知你：有沒有被錄取啊，還是被據了；你不用自己打電話去問結果，事實上也不能，你沒有HR的留聯系方式。
2 Reactor模式的優點
Reactor模式是編寫高性能網絡服務器的必備技術之一，它具有如下的優點：
1）響應快，不必為單個同步事件所阻塞，雖然Reactor本身依然是同步的；
2）編程相對簡單，可以最大程度的避免復雜的多線程及同步問題，並且避免了多線程/進程的切換開銷；
3）可擴展性，可以方便的通過增加Reactor實例個數來充分利用CPU資源；
4）可復用性，reactor框架本身與具體事件處理邏輯無關，具有很高的復用性。
3 Reactor模式框架
使用Reactor模型，必備的幾個組件：事件源、Reactor框架、多路復用機制和事件處理程序，先來看看Reactor模型的整體框架，接下來再對每個組件做逐一說明。
1）handle——事件源
Linux上是文件描述符，Windows上就是Socket或者Handle了，這里統一稱為“句柄集”；程序在指定的句柄上注冊關心的事件，在libevent中有三種類型的事件：定時器事件(time event)、信號事件(signal event)和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結構體。
4）Event Handler——事件處理程序
事件處理程序提供了一組接口，每個接口對應了一種類型的事件，供Reactor在相應的事件發生時調用，執行相應的事件處理。通常它會綁定一個有效的句柄。對應到libevent中，就是event結構體。
4 Reactor事件處理流程
在高性能服務器並發模型設計中,Reactor和Proactor是兩個經常用到的設計模式,前者用於同步IO,后者用於異步IO,前者在IO操作 就緒的情況下通知用戶,用戶再采取實際的IO操作,后者是在IO操作完成后通知用戶。
IOCP的設計就是Proactor 模式的完美體現,而epoll則很容易實現Reactor模式,asio設計為跨平台,並且在linux下采用epoll,我的印象中linux對異步 IO的支持沒有windows那么完善(看看IOCP和epoll模型的區別就知道),那么asio是怎么用epoll機制實現proactor模式的 呢,剛開始想的是應該在應用層做了一層封裝,就是asio內部應該有某個循環調用epoll_wait,當有IO事件就緒時幫用戶做一些操作(比如把數據 拷貝到我們提交的緩沖區),然后在操作完成的時候調用我們的handler(后來看代碼基本是這樣).OK,不說廢話了.
而異步同步IO的主要區別就是，應用發起一個 IO 操作以后，不等待內核 IO 操作的完成，等內核完成 IO 操作以后會通知應用程序，這其實就是同步和異步最關鍵的區別，同步必須等待或者主動的去詢問 IO 是否完成，顯然select和epoll是同步的。
另外本身Reactor模式就是同步的模式不是嗎？
如果你理解底層的select或者epoll。你會發現它其實是同步的。有一個while循環，等待事件觸發條件。滿足條件則調用相應的callback函數。因此本質上還是同步的。不過長了一個異步的臉