Memcached中的网络部分就是基于libevent完成的，其中的多线程模型就是典型的消息通知+同步层机制。
libevent是一个轻量级的基于事件驱动的高性能的开源网络库，并且支持多个平台，对多个平台的I/O复用技术进行了封装，当我们编译库的代码时，编译的脚本将会根据OS支持的处理事件机制，来编译相应的代码，从而在libevent接口上保持一致。

在当前的服务器上，面对的主要问题就是要能处理大量的连接。而通过libevent这个网络库，我们就可以调用它的API来很好的解决上面的问题。首先，可以来回顾一下，对这个问题的传统解决方法。

问题： 如何处理多个客户端连接

解决方案1：I/O复用技术

这几种方式都是同步I/O，即当读写事件就绪，他们自己需要负责进行读写，这个读写过程是阻塞的，而异步I/O则不需要自己负责读写，只需要通知负责读写的程序就可以了。

循环
假设当前我服务器有多个网络连接需要看管，那么我就循环遍历打开的网络连接的列表，来判断是否有要读取的数据。这种方法的缺点很明显，那就是 1.速度缓慢（必须遍历所有的网络连接） 2.效率低 （处理一个连接时可能发生阻塞，妨碍其他网络连接的检查和处理）

select方式
select对应于内核中的sys_select调用，sys_select首先将第二三四个参数指向的fd_set拷贝到内核，然后对每个被SET的描述符调用进行poll，并记录在临时结果中（fdset），如果有事件发生，select会将临时结果写到用户空间并返回；当轮询一遍后没有任何事件发生时，如果指定了超时时间，则select会睡眠到超时，睡眠结束后再进行一次轮询，并将临时结果写到用户空间，然后返回。
select返回后，需要逐一检查关注的描述符是否被SET（事件是否发生）。（select支持的文件描述符数量太小了，默认是1024）。

poll方式
poll与select不同，通过一个pollfd数组向内核传递需要关注的事件，故没有描述符个数的限制，pollfd中的events字段和revents分别用于标示关注的事件和发生的事件，故pollfd数组只需要被初始化一次。
poll的实现机制与select类似，其对应内核中的sys_poll，只不过poll向内核传递pollfd数组，然后对pollfd中的每个描述符进行poll，相比处理fdset来说，poll效率更高。
poll返回后，需要对pollfd中的每个元素检查其revents值，来得指事件是否发生。

epoll方式
epoll通过epoll_create创建一个用于epoll轮询的描述符，通过epoll_ctl添加/修改/删除事件，通过epoll_wait检查事件，epoll_wait的第二个参数用于存放结果。
epoll与select、poll不同，首先，其不用每次调用都向内核拷贝事件描述信息，在第一次调用后，事件信息就会与对应的epoll描述符关联起来。其次，epoll不是通过轮询，而是通过在等待的描述符上注册回调函数，当事件发生时，回调函数负责把发生的事件存储在就绪事件链表中，最后写到用户空间。
epoll返回后，该参数指向的缓冲区中即为发生的事件，对缓冲区中每个元素进行处理即可，而不需要像poll、select那样进行轮询检查。

解决方案2：多线程技术或多进程技术

多线程技术和多进程技术也可以处理高并发的数据连接，因为在服务器中可以产生大量的进程和线程和处理我们需要监视的连接。但是，这两种方式也是有很大的局限性的，比如多进程模型就不适合大量的短连接，因为进程的产生和关闭需要消耗较大的系统性能，同样，还要进程进程间的通信，在CPU性能不足的情况下不太适合。而多线程技术则不太适合处理长连接，因为当我们建立一个进程时，linux中会消耗8G的栈空间，如果我们的每个连接都杵着不断开，那么大量连接长连接后，导致的结果就是内存的大量消耗。

解决方案3：常用的上述二者复合使用
上述的两种方法各具有优缺点，因此，我们可以将上述的方法结合起来，这也是目前使用较多的处理高并发的方法。多进程+I/O复用或者多线程+I/O复用。而在具体的实现上，又可以分为很多的方式。比如多线程+I/O复用技术，我们使用使用一个主线程负责监听一个端口和接受的描述符是否有读写事件产生，如果有，则将事件分发给其他的工作进程去完成，这也是进程池的理念。

在说完上述的高并发的处理方法之后，我们可以来介绍一个libevent的主要特色了。

同样，lievent也是采用的上述系统提供的select，poll和epoll方法来进行I/O复用，但是针对于多个系统平台上的不同的I/O复用实现方式，libevent进行了重新的封装，并提供了统一的API接口。libevent在实现上使用了事件驱动这种机制，其本质上是一种Reactor模式。

Reactor模式，是一种事件驱动机制。应用程序需要提供相应的接口并注册到Reactor上，如果相应的事件发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”。

在Libevent中也是一样，向Libevent框架注册相应的事件和回调函数；当这些事件发生时，Libevent会调用这些回调函数处理相应的事件。

lbevent的事件支持三种，分别是网络IO、定时器和信号。定时器的数据结构使用最小堆（Min Heap），以提高效率。网络IO和信号的数据结构采用了双向链表(TAILQ)。

安装
libevent的安装很简单，我是直接从github上clone下一个源码，然后进行编译安装的。

具体的命令是（假设你已经安装了git）：

# git clone https://github.com/nmathewson/Libevent.git
# cd Libevent
# sh autogen.sh
# ./configure && make
# make install
# make verify //验证安装
2 Linux下libevent主要API介绍
现在的libevent版本已经到达libevent2了，其增加了多线程的支持，API函数也发生了一些微小的变化。

创建事件集

struct event_base *event_base_new(void)

创建事件

struct event event_new(struct event_base ,evutil_socket_t ,short ,event_callback_fn,void*)

参数一：事件所在的事件集。
参数二：socket的描述符。
参数三：事件类型，其中EV_READ表示等待读事件发生，EV_WRITE表示写事件发生，或者它俩的组合，EV_SIGNAL表示需要等待事件的号码，如 果不包含上述的标志，就是超时事件或者手动激活的事件。
参数四：事件发生时需要调用的回调函数。
参数五：回调函数的参数值。

添加事件和删除事件

int event_add(struct event * ev,const struct timeval* timeout)

参数一：需要添加的事件
参数二：事件的最大等待事件，如果是NULL的话，就是永久等待

int event_del(struct event *)
参数一：需要删除的事件

分配监听事件

int event_base_dispatch(struct event_base * )

参数一：需要监视的事件集

I/O buffer事件

struct bufferevent* bufferevent_socket_new
(struct event_base * base,evutil_socket_t fd,int options)

参数一：需要添加到的时间集
参数二：相关的文件描述符
参数三：0或者是相应的BEV_OPT_*可选标志

int bufferevent_enable(struct bufferevent * bev,short event)

参数一：需要启用的bufferevent
参数二：any combination of EV|READ | EV_WRITE

int bufferevent_disable(struct bufferevent * bev,short event)

参数说明：同上

size_t bufferevent_read(struct bufferevent bev,void data,size_t size)

参数一：读取的buffer_event事件
参数二：存储数据的指针
参数三：数据buffer的大小

返回值：读取数据的字节数

int bufferevent_write(struct bufferevent bev,const void data,size_t size)

参数一：读取的buffer_event事件
参数二：存储数据的指针
参数三：要写入的数据的大小，字节数

文件组织归类

1）头文主要就是 event.h：事件宏定义、接口函数声明，主要结构体 event 的声明；

2）内部头文件
xxx-internal.h：内部数据结构和函数，对外不可见，以达到信息隐藏的目的；
3） libevent 框架
event.c： event 整体框架的代码实现；
4）对系统 I/O 多路复用机制的封装
epoll.c：对 epoll 的封装；
select.c：对 select 的封装；
devpoll.c：对 dev/poll 的封装;
kqueue.c：对 kqueue 的封装；
5）定时事件管理
min-heap.h：其实就是一个以时间作为 key 的小根堆结构；
6）信号管理
signal.c：对信号事件的处理；
7）辅助功能函数
evutil.h 和 evutil.c：一些辅助功能函数，包括创建 socket pair 和一些时间操作函数：加、减
和比较等。
8）日志
log.h 和 log.c： log 日志函数
9）缓冲区管理
evbuffer.c 和 buffer.c： libevent 对缓冲区的封装；
10）基本数据结构
compat\sys 下的两个源文件： queue.h 是 libevent 基本数据结构的实现，包括链表，双向链表，
队列等； _libevent_time.h：一些用于时间操作的结构体定义、函数和宏定义；
11）实用网络库

http 和 evdns：是基于 libevent 实现的 http 服务器和异步 dns 查询库；

Libevent本身不是多线程安全的，在多核的时代，如何能充分利用CPU的能力呢，这一节来说说如何在多线程环境中使用libevent，跟源代码并没有太大的关系，纯粹是使用上的技巧。

1 错误使用示例
在多核的CPU上只使用一个线程始终是对不起CPU的处理能力啊，那好吧，那就多创建几个线程，比如下面的简单服务器场景。
1 主线程创建工作线程1；
2 接着主线程监听在端口上，等待新的连接；
3 在线程1中执行event事件循环，等待事件到来；
4 新连接到来，主线程调用libevent接口event_add将新连接注册到libevent上；
… …
上面的逻辑看起来没什么错误，在很多服务器设计中都可能用到主线程和工作线程的模式….
可是就在线程1注册事件时，主线程很可能也在操作事件，比如删除，修改，通过libevent的源代码也能看到，没有同步保护机制，问题麻烦了，看起来不能这样做啊，难道只能使用单线程不成！？

2 支持多线程的几种模式
Libevent并不是线程安全的，但这不代表libevent不支持多线程模式，其实方法在前面已经将signal事件处理时就接触到了，那就是消息通知机制。
一句话，“你发消息通知我，然后再由我在合适的时间来处理”；
说到这就再多说几句，再打个比方，把你自己比作一个工作线程，而你的头是主线程，你有一个消息信箱来接收别人发给你的消息，当时头有个新任务要指派给你。

2.1 暴力抢占
那么第一节中使用的多线程方法相当下面的流程：
1 当时你正在做事，比如在写文档；
2 你的头找到了一个任务，要指派给你，比如帮他搞个PPT，哈；
3 头命令你马上搞PPT，你这是不得不停止手头的工作，把PPT搞定了再接着写文档；
…

2.2 纯粹的消息通知机制
那么基于纯粹的消息通知机制的多线程方式就像下面这样：
1 当时你正在写文档；
2 你的头找到了一个任务，要指派给你，帮他搞个PPT；
3 头发个消息到你信箱，有个PPT要帮他搞定，这时你并不鸟他；
4 你写好文档，接着检查消息发现头有个PPT要你搞定，你开始搞PPT；
…
第一种的好处是消息可以立即得到处理，但是很方法很粗暴，你必须立即处理这个消息，所以你必须处理好切换问题，省得把文档上的内容不小心写到PPT里。在操作系统的进程通信中，消息队列（消息信箱）都是操作系统维护的，你不必关心。
第二种的优点是通过消息通知，切换问题省心了，不过消息是不能立即处理的（基于消息通知机制，这个总是难免的），而且所有的内容都通过消息发送，比如PPT的格式、内容等等信息，这无疑增加了通信开销。

2.3 消息通知+同步层
有个折中机制可以减少消息通信的开销，就是提取一个同步层，还拿上面的例子来说，你把工作安排都存放在一个工作队列中，而且你能够保证“任何人把新任务扔到这个队列”，“自己取出当前第一个任务”等这些操作都能够保证不会把队列搞乱（其实就是个加锁的队列容器）。
再来看看处理过程和上面有什么不同：
1 当时你正在写文档；
2 你的头找到了一个任务，要指派给你，帮他搞个PPT；
2 头有个PPT要你搞定，他把任务push到你的工作队列中，包括了PPT的格式、内容等信息；
3 头发个消息（一个字节）到你信箱，有个PPT要帮他搞定，这时你并不鸟他；
4 你写好文档，发现有新消息（这预示着有新任务来了），检查工作队列知道头有个PPT要你搞定，你开始搞PPT；
…
工作队列其实就是一个加锁的容器（队列、链表等等），这个很容易实现实现；而消息通知仅需要一个字节，具体的任务都push到了在工作队列中，因此想比2.2减少了不少通信开销。
多线程编程有很多陷阱，线程间资源的同步互斥不是一两句能说得清的，而且出现bug很难跟踪调试；这也有很多的经验和教训，因此如果让我选择，在绝大多数情况下都会选择机制3作为实现多线程的方法。