简介
说到异步IO,高并发之类的名词， 可能很多人第一反应就是 select, poll, epoll, kqueue 之类的底层代码库。 但是其实除非你要写一个 Nginx 性能级别的服务器， 否则直接使用 epoll 之类的还是太过底层， 诸多不便，要榨干整个异步编程的高并发性能还需要开发很多相关组件， 而 Libevent 就是作为更好用的高性能异步编程网络库而生， 他帮你包装了各种 buffer 和 event， 甚至也提供了更加高层的 http 和 rpc 等接口， 可以让你脱离底层细节，更加专注于服务的其他核心功能的实现。 当然，要真正用好它，还是需要懂不少关于他的实现原理。
如果是第一次接触 Libevent 的可以先看一篇非常好的入门文章： Libevent-book ， 文章主要从 C10K 问题的发展循序渐进， 分别讲了在高并发连接的情况下， 多线程解决方案， 多进程解放方案会遇到的问题， 从而引出为什么异步IO是当前解决高并发连接最有效的方案。
ideawu 实现的 C1000K 服务器 icomet 核心就是基于 Libevent 实现的。
本文源码分析基于 Libevent master 分支
commit 6dba1694c89119c44cef03528945e5a5978ab43a版本的代码。
事件循环
既然是异步IO，事件驱动，自然会有事件循环(event loop) 。 Libevent 的事件循环是通过调用 event_base_dispatch 来实现， 其实 event_base_dispatch 函数也是调用了 event_base_loop， 代码如下：
int event_base_dispatch(struct event_base *event_base) { return (event_base_loop(event_base, 0)); } 运行事件循环的函数肯定是阻塞函数， 拿 linux 平台来说， libevent 的事件循环其实就是循环调用 epoll_wait 函数，
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); 在没有任何事件被触发的时候，epoll_wait 是阻塞等待的， 而且，在 Libevent 里，定时器的实现其实就是通过 epoll_wait 的 timeout 参数实现的。
如果只有一个单线程的话，一旦调用了 event_base_dispatch 之后，这个线程就会被事件完完全全的霸占， 无法进行任何其他的操作。
如果我们需要临时手动激活任何其他事件的话， 则需要借助另一个线程来操作(因为主线程仍然在阻塞等待中)。
在 event_active 函数的解释里面就有一句话说的就是这个事情：
One common use in multithreaded programs is to wake the thread running event_base_loop() from another thread. 事件是 Libevent 的最小单位
这里的事件指的就是 struct event 数据结构。
事件可以注册的各种信号如下：
#define EV_TIMEOUT 0x01 Indicates that a timeout has occurred. #define EV_READ 0x02 Wait for a socket or FD to become readable. #define EV_WRITE 0x04 Wait for a socket or FD to become writeable. #define EV_SIGNAL 0x08 Wait for a POSIX signal to be raised. #define EV_PERSIST 0x10 Persistent event: won't get removed automatically when activated. #define EV_ET 0x20 Select edge-triggered behavior, if supported by the backend. 几乎所有其它更上层的数据结构都是基于 struct event 的包装来完成的。
核心数据结构
就拿 基于 Libevent 写一个 HTTP 服务器举例来说说， 编程时需要理解的几个核心数据结构是：
- evhttp_request
- evhttp_connection
- bufferevent
- evbuffer
从上到下是从高层到底层的关系， 下文的顺序也是从高层往底层分析。
evhttp_request
struct evhttp_request { // 每个 evhttp_request 都内含一个 evhttp_connection 来负责数据传输 struct evhttp_connection *evcon; //输入输出的两个buffer（这两个buffer的数据是从 evhttp_connection 里面的 input_buffer 和 output_buffer 拷贝过来的。） struct evbuffer *input_buffer; /* read data */ ev_int64_t ntoread; unsigned chunked:1, /* a chunked request */ userdone:1; /* the user has sent all data */ struct evbuffer *output_buffer; /* outgoing post or data */ //和HTTP协议有关的各种回调函数： void (*cb)(struct evhttp_request *, void *); void *cb_arg; void (*chunk_cb)(struct evhttp_request *, void *); int (*header_cb)(struct evhttp_request *, void *); void (*error_cb)(enum evhttp_request_error, void *); void (*on_complete_cb)(struct evhttp_request *, void *); void *on_complete_cb_arg; // 其它 // ...... }; evhttp_connection
evhttp_request 和 evhttp_connection 的关系很简单，拿协议栈来对比的话， 前者代表的是 HTTP 协议，即应用层协议， 后者代表的是 TCP 协议，即传输层协议。 前者需要管理所有和 HTTP 相关的数据内容，比如 HTTP header 数据和 body 数据。
struct evhttp_connection { // socket文件描述符 evutil_socket_t fd; // evhttp_connection 含有一个bufferevent，基于它进行数据传输。 struct bufferevent *bufev; // 和数据传输有关的状态 enum evhttp_connection_state state; //和 HTTP 协议无关的数据传输回调函数 void (*cb)(struct evhttp_connection *, void *); void *cb_arg; void (*closecb)(struct evhttp_connection *, void *); void *closecb_arg; // 其它 // ...... }; evhttp_connection 结构里面含有 enum evhttp_connection_state state 变量， 这个和 Thrift异步IO服务器源码分析 里面的 保持每个连接的状态是一个道理。 维护状态变化是异步IO服务编程的必要条件。
enum evhttp_connection_state { EVCON_DISCONNECTED, /**< not currently connected not trying either*/ EVCON_CONNECTING, /**< tries to currently connect */ EVCON_IDLE, /**< connection is established */ EVCON_READING_FIRSTLINE,/**< reading Request-Line (incoming conn) or **< Status-Line (outgoing conn) */ EVCON_READING_HEADERS, /**< reading request/response headers */ EVCON_READING_BODY, /**< reading request/response body */ EVCON_READING_TRAILER, /**< reading request/response chunked trailer */ EVCON_WRITING /**< writing request/response headers/body */ }; bufferevent
bufferevent 就是包装了 EV_READ event 和 EV_WRITE event ， 并且带有读写缓冲区(evbuffer)的更高层的单位。
struct bufferevent { // 读写事件 struct event ev_read; struct event ev_write; // 读写缓冲区 struct evbuffer *input; struct evbuffer *output; // 注意三个回调函数是核心 bufferevent_data_cb readcb; bufferevent_data_cb writecb; bufferevent_event_cb errorcb; void *cbarg; // 其他 // ...... }; 我觉得上面代码就非常简洁易懂了， 两个读写时间没什么好说的， 两个读写缓冲区也是必须的（evbuffer的实现在后面会谈到）， 三个回调函数就是核心。 读和写的回调函数没什么好说的， 唯一需要注意的是 bufferevent_event_cb errorcb 这个回调函数是必须注册的， 它关系到当该 bufferevent 对应的时间发生读写外的任何行为（比如socket关闭）时， 都会触发。
整理一遍 bufferevent 的事件处理过程就是：
- 当可读事件发生时，调用 readcb 将 socket 的数据 通过 recv 读出来存入 input 缓冲区；
- 当可写事件发生时，调用 writecb 将 output 缓冲区里面的数据通过 socket send 发送出去；
- 当其他事件发生时，比如 socket close 发生，进行相应的数据清理退出工作。
evbuffer
基本上的异步IO服务里的buffer都是一个德行（包括Nginx也是这样）， 都是即是数组又是链表（类似C++ STL里面的deque）。 对于 libevent 来说， evbuffer 是一个链表，管理整个缓冲区的头指针和尾指针，
struct evbuffer { struct evbuffer_chain *first; struct evbuffer_chain *last; size_t total_len; //...... }; 对于 evbuffer 这个链表的每个单元，也就是 evbuffer_chain 来说， 则是数组（连续内存空间），
struct evbuffer_chain { struct evbuffer_chain *next; size_t buffer_len; size_t off; unsigned char *buffer; //...... }; 总结
对于我个人而言，读源码的时候主要是从核心数据结构入手， 如果理解了这几个核心数据结构， 一般就能猜到这些数据结构的相关函数都有哪些。 可以围绕着这些结构去找相关的函数为己所用。
