C1000K之Libevent源码分析

简介

说到异步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;
    //......
};

总结

对于我个人而言，读源码的时候主要是从核心数据结构入手，如果理解了这几个核心数据结构，一般就能猜到这些数据结构的相关函数都有哪些。可以围绕着这些结构去找相关的函数为己所用。

http://yanyiwu.com/work/2014/12/10/asyncronous-io-libevent.html

时间： 2024-10-27 05:59:37

C1000K之Libevent源码分析

简介

事件循环

事件是 Libevent 的最小单位

核心数据结构

evhttp_request

evhttp_connection

bufferevent

evbuffer

总结

C1000K之Libevent源码分析的相关文章

Thrift异步IO服务器源码分析

WebWork2源码分析

JUnir源码分析（一）

java io学习（三）管道的简介,源码分析和示例

java io学习（二）ByteArrayOutputStream的简介,源码分析和示例

java io学习（一）ByteArrayInputStream的简介,源码分析和示例

mahout源码分析之DistributedLanczosSolver（七）总结篇

mahout源码分析之DistributedLanczosSolver（五）

Jquery源码分析---概述