高并发服务器epoll接口、epoll Reactor(反应堆)模型详解

epoll接口是为解决Linux内核处理大量文件描述符而提出的方案。该接口属于Linux下多路I/O复用接口中select/poll的增强。其经常应用于Linux下高并发服务型程序，特别是在大量并发连接中只有少部分连接处于活跃下的情况 (通常是这种情况)，在该情况下能显著的提高程序的CPU利用率。

epoll采用的是事件驱动，并且设计的十分高效。在用户空间获取事件时，不需要去遍历被监听描述符集合中所有的文件描述符，而是遍历那些被内核I/O事件异步唤醒之后加入到就绪队列并返回到用户空间的描述符集合。 
epoll提供了两种触发模式，水平触发(LT)和边沿触发(ET)。当然，涉及到I/O操作也必然会有阻塞和非阻塞两种方案。目前效率相对较高的是 epoll+ET+非阻塞I/O 模型，在具体情况下应该合理选用当前情形中最优的搭配方案。

接下来的讲解顺序为： 
(1) epoll接口的一般使用 
(2) epoll接口 + 非阻塞 
(3) epoll接口 + 非阻塞 + 边沿触发 
(4) epoll反应堆模型 （重点，Libevent库的核心思想）

一、epoll接口的基本思想概述
epoll的设计： 
（1）epoll在Linux内核中构建了一个文件系统，该文件系统采用红黑树来构建，红黑树在增加和删除上面的效率极高，因此是epoll高效的原因之一。有兴趣可以百度红黑树了解，但在这里你只需知道其算法效率超高即可。 
（2）epoll红黑树上采用事件异步唤醒，内核监听I/O，事件发生后内核搜索红黑树并将对应节点数据放入异步唤醒的事件队列中。 
（3）epoll的数据从用户空间到内核空间采用mmap存储I/O映射来加速。该方法是目前Linux进程间通信中传递最快,消耗最小,传递数据过程不涉及系统调用的方法。 

epoll接口相对于传统的select/poll而言，有以下优点： 
（1）支持单个进程打开大数量的文件描述符。受进程最大打开的文件描述符数量限制，而不是受自身实现限制。而select单个进程能够打开的文件描述符的数量存在最大限制，这个限制是select自身实现的限制。通常是1024。poll采用链表，也是远超select的。 
（2）Linux的I/O效率不会随着文件描述符数量的增加而线性下降。较之于select/poll，当处于一个高并发时(例如10万，100万)。在如此庞大的socket集合中，任一时间里其实只有部分的socket是“活跃”的。select/poll的处理方式是，对用如此庞大的集合进行线性扫描并对有事件发生的socket进行处理，这将极大的浪费CPU资源。因此epoll的改进是，由于I/O事件发生，内核将活跃的socket放入队列并交给mmap加速到用户空间，程序拿到的集合是处于活跃的socket集合，而不是所有socket集合。 
（3）使用mmap加速内核与用户空间的消息传递。select/poll采用的方式是，将所有要监听的文件描述符集合拷贝到内核空间（用户态到内核态切换）。接着内核对集合进行轮询检测，当有事件发生时，内核从中集合并将集合复制到用户空间。 再看看epoll怎么做的，内核与程序共用一块内存，请看epoll总体描述01这幅图，用户与mmap加速区进行数据交互不涉及权限的切换(用户态到内核态，内核态到用户态)。内核对于处于非内核空间的内存有权限进行读取。 
 

接下来我们结合epoll总体描述01与上述的内容，将图示进行升级为epoll总体描述02。 

 

让我们来看看图的红黑树文件系统。以epfd为根，挂载了一个监听描述符和5个与客户端建立连接的cfd。fd的增删按照红黑树的操作方式，每一个文件描述符都有一个对应的结构，该结构为

/*
 *  -[ epoll结构体描述01 ]-
 */
struct epoll_event {
            __uint32_t events; /* Epoll events */
            epoll_data_t data; /* User data variable */
        };

typedef union epoll_data {
            void *ptr;
            int fd;
            uint32_t u32;
            uint64_t u64;
    &n