说透IO多路复用模型

作者：京东零售 石向阳

在说IO多路复用模型之前，咱们先来大致了解下Linux文件体系。在Linux体系中，不论是你的鼠标，键盘，仍是打印机，乃至于衔接到本机的socket client端，都是以文件描绘符的形式存在于体系中，诸如此类，等等等等，所以能够这么说，一切皆文件。来看一下体系界说的文件描绘符阐明：





从上面的列表能够看到，文件描绘符0,1,2都现已被体系占用了，当体系启动的时分，这三个描绘符就存在了。其中0代表规范输入，1代表规范输出，2代表过错输出。当咱们创立新的文件描绘符的时分，就会在2的基础上进行递加。能够这么说，文件描绘符是为了办理被翻开的文件而创立的体系索引，他代表了文件的身份ID。对标windows的话，你能够以为和句柄相似，这样就更容易了解一些。

因为网上对linux文件这块的原理描绘的文章现已非常多了，所以这儿我不再做过多的赘述，感兴趣的同学能够从Wikipedia翻阅一下。因为这块内容比较复杂，不归于本文普及的内容，主张读者另行自研，这儿我非常引荐马战士老师将linux文件体系这块，解说的真的非常好。

select模型

此模型是IO多路复用的最前期运用的模型之一，距今现已几十年了，可是现在依旧有不少运用还在选用此种方法，可见其长生不老。首要来看下其具体的界说（来源于man二类文档）：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds, struct timeval *timeout);

这儿解释下其具体参数：

参数一：nfds，也即maxfd，最大的文件描绘符递加一。这儿之所以传最大描绘符，为的便是在遍历fd_set的时分，限定遍历规模。

参数二：readfds，可读文件描绘符调集。

参数三：writefds，可写文件描绘符调集。

参数四：errorfds，反常文件描绘符调集。

参数五：timeout，超时时刻。在这段时刻内没有检测到描绘符被触发，则回来。

下面的宏处理，能够对fd_set调集（准确的说是bitmap，一个描绘符有改变，则会在描绘符对应的索引处置1）进行操作：

FD_CLR(inr fd,fd_set* set) 用来铲除描绘词组set中相关fd 的位，即bitmap结构中索引值为fd的值置为0。

FD_ISSET(int fd,fd_set *set) 用来测验描绘词组set中相关fd 的位是否为真，即bitmap结构中某一位是否为1。

FD_SET（int fd,fd_set*set） 用来设置描绘词组set中相关fd的位，行将bitmap结构中某一位设置为1，索引值为fd。

FD_ZERO（fd_set *set） 用来铲除描绘词组set的悉数位，行将bitmap结构悉数清零。

首要来看一段服务端选用了select模型的示例代码：

//创立server端套接字，获取文件描绘符
    int listenfd = socket(PF_INET,SOCK_STREAM,0);
    if(listenfd < 0) return -1;
    //绑定服务器
    bind(listenfd,(struct sockaddr*)&address,sizeof(address));
    //监听服务器
    listen(listenfd,5); 
    struct sockaddr_in client;
    socklen_t addr_len = sizeof(client);
    //接纳客户端衔接
    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);
    //读缓冲区
    char buff[1024]; 
    //读文件操作符
    fd_set read_fds;  
    while(1)
    {
        memset(buff,0,sizeof(buff));
        //留意：每次调用select之前都要从头设置文件描绘符connfd，因为文件描绘符表会在内核中被修正
        FD_ZERO(&read_fds);
        FD_SET(connfd,&read_fds);
        //留意：select会将用户态中的文件描绘符表放到内核中进行修正，内核修正结束后再回来给用户态，开支较大
        ret = select(connfd+1,&read_fds,NULL,NULL,NULL);
        if(ret < 0)
        {
            printf("Fail to select!\n");
            return -1;
        }
        //检测文件描绘符表中相关恳求是否可读
        if(FD_ISSET(connfd, &read_fds))
        {
            ret = recv(connfd,buff,sizeof(buff)-1,0);
            printf("receive %d bytes from client: %s \n",ret,buff);
        }
    }

上面的代码我加了比较具体的注释了，咱们应该很容易看明白，说白了大约流程其实如下：

首要，创立socket套接字，创立结束后，会获取到此套接字的文件描绘符。

然后，bind到指定的地址进行监听listen。这样，服务端就在特定的端口启动起来并进行监听了。

之后，运用敞开accept方法来监听客户端的衔接恳求。一旦有客户端衔接，则将获取到当时客户端衔接的connection文件描绘符。

两边树立衔接之后，就能够进行数据互传了。需求留意的是，在循环开始的时分，务必每次都要从头设置当时connection的文件描绘符，是因为文件描描绘符表在内核中被修正过，假如不重置，将会导致反常的状况。

从头设置文件描绘符后，就能够运用select函数从文件描绘符表中，来轮询哪些文件描绘符安排妥当了。此刻体系会将用户态的文件描绘符表发送到内核态进行调整，行将预备安排妥当的文件描绘符进行置位，然后再发送给用户态的运用中来。

用户经过FD_ISSET方法来轮询文件描绘符，假如数据可读，则读取数据即可。

举个例子，假定此刻衔接上来了3个客户端，connection的文件描绘符分别为 4,8,12，那么其read_fds文件描绘符表（bitmap结构）的大致结构为 00010001000100000….0，因为read_fds文件描绘符的长度为1024位，所以最多答应1024个衔接。





而在select的时分，涉及到用户态和内核态的转化，所以全体转化方法如下：





所以，综合起来，select全体仍是比较高效和安稳的，可是呈现出来的问题也不少，这些问题进一步约束了其功能发挥：

1. 文件描绘符表为bitmap结构，且有长度为1024的约束。

2. fdset无法做到重用，每次循环有必要从头创立。

3. 频频的用户态和内核态复制，功能开支较大。

4. 需求对文件描绘符表进行遍历，O(n)的轮询时刻复杂度。

poll模型

考虑到select模型的几个约束，后来进行了改善，这也便是poll模型，既然是select模型的改善版，那么必定有其亮眼的地方，一起来看看吧。当然，这次咱们依旧是先翻阅linux man二类文档，因为这是官方的文档，对其有着最为精准的界说。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

其实，从运行机制上说来，poll所做的功能和select是根本上相同的，都是等候并检测一组文件描绘符安排妥当，然后在进行后续的IO处理作业。只不过不同的是，select中，选用的是bitmap结构，长度限定在1024位的文件描绘符表，而poll模型则选用的是pollfd结构的数组fds，也正是因为poll模型选用了数组结构，则不会有1024长度约束，使其能够接受更高的并发。

pollfd结构内容如下：

struct pollfd {
    int   fd;         /* 文件描绘符 */
    short events;     /* 关怀的事情 */
    short revents;    /* 实践回来的事情 */
};

从上面的结构能够看出，fd很明显便是指文件描绘符，也便是当客户端衔接上来后，fd会将生成的文件描绘符保存到这儿；而events则是指用户想重视的事情；revents则是指实践回来的事情，是由体系内核填充并回来，假如当时的fd文件描绘符有状况改变，则revents的值就会有相应的改变。

events事情列表如下：





revents事情列表如下：





从列表中能够看出，revents是包括events的。接下来结合示例来看一下：

//创立server端套接字，获取文件描绘符
    int listenfd = socket(PF_INET,SOCK_STREAM,0);
    if(listenfd < 0) return -1;
    //绑定服务器
    bind(listenfd,(struct sockaddr*)&address,sizeof(address));
    //监听服务器
    listen(listenfd,5); 
    struct pollfd pollfds[1];
    socklen_t addr_len = sizeof(client);
    //接纳客户端衔接
    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);
    //放入fd数组
    pollfds[0].fd = connfd;
    pollfds[0].events = POLLIN;
    //读缓冲区
    char buff[1024]; 
    //读文件操作符
    fd_set read_fds;  
    while(1)
    {
        memset(buff,0,sizeof(buff));
        /**
         ** SELECT模型专用
         ** 留意：每次调用select之前都要从头设置文件描绘符connfd，因为文件描绘符表会在内核中被修正
         ** FD_ZERO(&read_fds);
         ** FD_SET(connfd,&read_fds);
        ** 留意：select会将用户态中的文件描绘符表放到内核中进行修正，内核修正结束后再回来给用户态，开支较大
        ** ret = select(connfd+1,&read_fds,NULL,NULL,NULL);
        **/
        ret = poll(pollfds, 1, 1000);
        if(ret < 0)
        {
            printf("Fail to poll!\n");
            return -1;
        }
        /**
         ** SELECT模型专用
         ** 检测文件描绘符表中相关恳求是否可读
         ** if(FD_ISSET(connfd, &read_fds))
         ** {
         **   ret = recv(connfd,buff,sizeof(buff)-1,0);
         **   printf("receive %d bytes from client: %s \n",ret,buff);
         ** }
         **/
        //检测文件描绘符数组中相关恳求
        if(pollfds[0].revents & POLLIN){
            pollfds[0].revents = 0;
            ret = recv(connfd,buff,sizeof(buff)-1,0);
            printf("receive %d bytes from client: %s \n",ret,buff);
        }
    }

因为源码中，我做了比较具体的注释，一起将和select模型不相同的地方都列了出来，这儿就不再具体解释了。总体说来，poll模型比select模型要好用一些，去掉了一些约束，可是仍然避免不了如下的问题：

1. 用户态和内核态仍需求频频切换，因为revents的赋值是在内核态进行的，然后再推送到用户态，和select相似，全体开支较大。

2. 仍需求遍历数组，时刻复杂度为O（N）。

epoll模型

假如说select模型和poll模型是前期的产物，在功能上有许多不尽人意之处，那么自linux 2.6之后新增的epoll模型，则完全处理了功能问题，一举使得单机接受百万并发的课题变得极为容易。现在能够这么说，只需求一些简略的设置更改，然后配合上epoll的功能，完成单机百万并发轻而易举。一起，因为epoll全体的优化，使得之前的几个比较消耗功能的问题不再成为纠缠，所以也成为了linux平台上进行网络通讯的首选模型。

解说之前，仍是linux man文档镇楼：linux man epoll 4类文档 linux man epoll 7类文档，俩文档结合着读，会对epoll有个大约的了解。和之前说到的select和poll不同的是，此二者皆归于体系调用函数，可是epoll则不然，他是存在于内核中的数据结构，能够经过epoll_create，epoll_ctl及epoll_wait三个函数结合来对此数据结构进行操控。

说道epoll_create函数，其效果是在内核中创立一个epoll数据结构实例，然后将回来此实例在体系中的文件描绘符。此epoll数据结构的组成其实是一个链表结构，咱们称之为interest list，里面会注册衔接上来的client的文件描绘符。

其简化作业机制如下：





说道epoll_ctl函数，其效果则是对epoll实例进行增删改查操作。有些相似咱们常用的CRUD操作。这个函数操作的目标其实便是epoll数据结构，当有新的client衔接上来的时分，他会将此client注册到epoll中的interest list中，此操作经过附加EPOLL_CTL_ADD符号来完成；当已有的client掉线或许自动下线的时分，他会将下线的client从epoll的interest list中移除，此操作经过附加EPOLL_CTL_DEL符号来完成；当有client的文件描绘符有改变的时分，他会将events中的对应的文件描绘符进行更新，此操作经过附加EPOLL_CTL_MOD来完成；当interest list中有client现已预备好了，能够进行IO操作的时分，他会将这些clients拿出来，然后放到一个新的ready list里面。

其简化作业机制如下：





说道epoll_wait函数，其效果便是扫描ready list，处理预备安排妥当的client IO，其回来成果即为预备好进行IO的client的个数。经过遍历这些预备好的client，就能够轻松进行IO处理了。

上面这三个函数是epoll操作的根本函数，可是，想要完全了解epoll，则需求先了解这三块内容，即：inode，链表，红黑树。

在linux内核中，针对当时翻开的文件，有一个open file table，里面记载的是一切翻开的文件描绘符信息；一起也有一个inode table，里面则记载的是底层的文件描绘符信息。这儿假如文件描绘符B fork了文件描绘符A，尽管在open file table中，咱们看新增了一个文件描绘符B，可是实践上，在inode table中，A和B的底层是一模相同的。这儿，将inode table中的内容了解为windows中的文件属性，会愈加恰当和易懂。这样存储的优点便是，无论上层文件描绘符怎样改变，因为epoll监控的数据永远是inode table的底层数据，那么我就能够一向能够监控到文件的各种改变信息，这也是epoll高效的基础。更多具体信息，请参阅这两篇文章：Nonblocking IO & The method to epoll’s madness.

简化流程如下：





数据存储这块处理了，那么针对衔接上来的客户端socket，该用什么数据结构保存进来呢？这儿用到了红黑树，因为客户端socket会有频频的新增和删除操作，而红黑树这块时刻复杂度仅仅为O(logN)，仍是挺高效的。有人会问为啥不用哈希表呢？当大量的衔接频频的进行接入或许断开的时分，扩容或许其他行为将会发生不少的rehash操作，并且还要考虑哈希抵触的状况。尽管查询速度的确能够达到o(1)，可是rehash或许哈希抵触是不可控的，所以根据这些考量，我以为红黑树占优一些。

客户端socket怎样办理这块处理了，接下来，当有socket有数据需求进行读写事情处理的时分，体系会将现已安排妥当的socket添加到双向链表中，然后经过epoll_wait方法检测的时分，其实检查的便是这个双向链表，因为链表中都是安排妥当的数据，所以避免了针对整个客户端socket列表进行遍历的状况，使得全体效率大大提高。 全体的操作流程为：

首要，运用epoll_create在内核中创立一个epoll目标。其实这个epoll目标，便是一个能够存储客户端衔接的数据结构。

然后，客户端socket衔接上来，会经过epoll_ctl操作将成果添加到epoll目标的红黑树数据结构中。

然后，一旦有socket有事情发生，则会经过回调函数将其添加到ready list双向链表中。

最终，epoll_wait会遍历链表来处理现已预备好的socket，然后经过预先设置的水平触发或许边际触发来进行数据的感知操作。

从上面的细节能够看出，因为epoll内部监控的是底层的文件描绘符信息，能够将改变的描绘符直接加入到ready list，无需用户将一切的描绘符再进行传入。一起因为epoll_wait扫描的是现已安排妥当的文件描绘符，避免了许多无效的遍历查询，使得epoll的全体功能大大提高，能够说现在只需谈论linux平台的IO多路复用，epoll现已成为了不贰之选。

水平触发和边际触发

上面说到了epoll，首要解说了client端怎样连进来，可是并未具体的解说epoll_wait怎样被唤醒的，这儿我将来具体的解说一下。

水平触发，意即Level Trigger，边际触发，意即Edge Trigger，假如单从字面意思上了解，则不太容易，可是假如将硬件设计中的水平沿，上升沿，下降沿的概念引进来，则了解起来就容易多了。比方咱们能够这样以为：





假如将上图中的方块看做是buffer的话，那么了解起来则就愈加容易了，比方针对水平触发，buffer只需是一向有数据，则一向告诉；而边际触发，则buffer容量发生改变的时分，才会告诉。尽管能够这样简略的了解，可是实践上，其细节处理部分，比图示中展示的愈加精细，这儿来具体的说一下。

边际触发

针对读操作，也便是当时fd处于EPOLLIN形式下，即可读。此刻意味着有新的数据到来，接纳缓冲区可读，以下buffer都指接纳缓冲区：

1. buffer由空变为非空，意即有数据进来的时分，此进程会触发告诉。





2. buffer本来有些数据，这时分又有新数据进来的时分，数据变多，此进程会触发告诉。





3. buffer中有数据，此刻用户对操作的fd注册EPOLL_CTL_MOD事情的时分，会触发告诉。





针对写操作，也便是当时fd处于EPOLLOUT形式下，即可写。此刻意味着缓冲区能够写了，以下buffer都指发送缓冲区：

1. buffer满了，这时分发送出去一些数据，数据变少，此进程会触发告诉。





2. buffer本来有些数据，这时分又发送出去一些数据，数据变少，此进程会触发告诉。





这儿便是ET这种形式触发的几种情形，能够看出，根本上都是围绕着接纳缓冲区或许发送缓冲区的状况改变来进行的。

不流畅难懂？不存在的，举个栗子：

在服务端，咱们敞开边际触发形式，然后将buffer size设为10个字节，来看看具体的表现形式。

服务端敞开，客户端衔接，发送单字符A到服务端，输出成果如下：

-->ET Mode: it was triggered once

get 1 bytes of content: A

-->wait to read!

能够看到，因为buffer从空到非空，边际触发告诉发生，之后在epoll_wait处堵塞，继续等候后续事情。

这儿咱们变一下，输入ABCDEFGHIJKLMNOPQ，能够看到，客户端发送的字符长度超过了服务端buffer size，那么输出成果将是怎样样的呢？

-->ET Mode: it was triggered once

get 9 bytes of content: ABCDEFGHI

get 8 bytes of content: JKLMNOPQ

-->wait to read!

能够看到，这次发送，因为发送的长度大于buffer size，所以内容被折成两段进行接纳，因为用了边际触发方法，buffer的状况是从空到非空，所以只会发生一次告诉。

水平触发

水平触发则简略多了，他包括了边际触发的一切场景，简而言之如下：

当接纳缓冲区不为空的时分，有数据可读，则读事情会一向触发。





当发送缓冲区未满的时分，能够继续写入数据，则写事情一向会触发。





相同的，为了使表达更明晰，咱们也来举个栗子，依照上述入输入方法来进行。

服务端敞开，客户端衔接并发送单字符A，能够看到服务端输出状况如下：

-->LT Mode: it was triggered once!

get 1 bytes of content: A

这个输出成果，毋庸置疑，因为buffer中有数据，所以水平形式触发，输出了成果。

服务端敞开，客户端衔接并发送ABCDEFGHIJKLMNOPQ，能够看到服务端输出状况如下：

-->LT Mode: it was triggered once!

get 9 bytes of content: ABCDEFGHI

-->LT Mode: it was triggered once!

get 8 bytes of content: JKLMNOPQ

从成果中，能够看出，因为buffer中数据读取结束后，还有未读完的数据，所以水平形式会一向触发，这也是为啥这儿水平形式被触发了两次的原因。

有了这两个栗子的比对，不知道聪明的你，get到二者的差异了吗？

在实践开发进程中，实践上LT更易用一些，毕竟体系协助咱们做了大部分校验告诉作业，之前说到的SELECT和POLL，默认选用的也都是这个。可是需求留意的是，当有成千上万个客户端衔接上来开始进行数据发送，因为LT的特性，内核会频频的处理告诉操作，导致其相对于ET来说，比较的消耗体系资源，所以，跟着客户端的增多，其功能也就越差。

而边际触发，因为监控的是FD的状况改变，所以全体的体系告诉并没有那么频频，高并发下全体的功能表现也要好许多。可是因为此形式下，用户需求积极的处理好每一笔数据，带来的维护代价也是相当大的，稍微不留意就有或许犯错。所以运用起来需求非常小心才行。

至于二者如何选择，诸位就仁者见仁智者见智吧。

行文到这儿，关于epoll的解说根本上结束了，咱们从中是不是学到了许多干货呢？ 因为从netty研讨到linux epoll底层，其难度非常大，能够用曲高和寡来描述，所以在这块探究的文章是比较少的，许多东西需求自己照着man文档和源码一点一点的琢磨（linux源码详见eventpoll.c等）。这儿我来纠正一下搜索引擎上，说epoll高功能是因为运用mmap技能完成了用户态和内核态的内存同享，所以功能好，我前期被这个观念误导了好久，后来下来了linux源码，翻了一下，并没有在epoll中翻到mmap的技能点，所以这个观念是过错的。这些过错观念的文章，国内不少，国外也不少，希望咱们能审慎选择，避免被过错带偏。

所以，epoll高功能的根本便是，其高效的文件描绘符处理方法加上颇具特性边的缘触发处理形式，以很少的内核态和用户态的切换，完成了真正意义上的高并发。