原副标题：说透IO数据通信数学模型
译者：天猫零售业 石顺义
在说IO数据通信数学模型以后，他们先来大体介绍下Linux文档控制系统。在Linux控制系统中，无论是你的滑鼠，按键，还是印表机，班莱班县相连到Yak的socket client端，都是以文档配置文档的方式存有于控制系统中，譬如，Bokaro，因此能那么说，所有人皆文档。上看呵呵控制系统表述的文档配置文档表明：
从下面的条目能看见，文档配置文档0,1,2都早已被控制系统挤占了，当系统启动的这时候，这四个配置文档就存有了。其中0代表者国际标准输出，1代表者国际标准输出，2代表者严重错误输出。当他们建立捷伊文档配置文档的这时候，就会在2的基础上进行递减。能那么说，文档配置文档是为的是管理工作被关上的文档而建立的系统检索，他代表者了文档的身分ID。Kanniyakumariwindows不然，你能认为和标识符类似于，这样就更容易认知一些。
虽然网路上对linux文档那块的基本原理叙述的该文早已十分多了，因此这儿我无须做过多的约勒，钟爱的同学可以从Wikipedia翻看呵呵。虽然那块文本非常复杂，不属于责任编辑普及化的文本，提议听众自行暗鞘，这儿我十分所推荐马战俘同学将linux文档控制系统那块，传授的吗十分好。
select数学模型
此数学模型是IO数据通信的
int select(intnfds, 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数学模型的示例代码：
/
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);
}
}
下面的代码我加了比较详细的注释了，大家应该很容易看明白，说白了大概流程其实如下：
然后，bind到指定的地址进行监听listen。这样，服务端就在特定的端口启动起来并进行监听了。
双方建立相连之后，就可以进行数据互传了。需要注意的是，在循环开始的这时候，务必每次都要重新设置当前connection的文档配置文档，是因为文档描配置文档表在内核中被修改过，如果不重置，将会导致异常的情况。
重新设置文档配置文档后，就能利用select函数从文档配置文档表中，来轮询哪些文档配置文档就绪了。此时控制系统会将用户态的文档配置文档表发送到内核态进行调整，即将准备就绪的文档配置文档进行置位，然后再发送给用户态的应用中来。
用户通过FD_ISSET方法来轮询文档配置文档，如果数据可读，则读取数据即可。
举个例子，假设此时相连上来了3个客户端，connection的文档配置文档分别为 4,8,12，那么其read_fds文档配置文档表（bitmap结构）的大体结构为 00010001000100000….0，虽然read_fds文档配置文档的长度为1024位，因此最多允许1024个相连。
而在select的这时候，涉及到用户态和内核态的转换，因此整体转换方式如下：
因此，综合起来，select整体还是比较高效和稳定的，但是呈现出来的问题也不少，这些问题进一步限制了其性能发挥：
文档配置文档表为bitmap结构，且有长度为1024的限制。 fdset无法做到重用，每次循环必须重新建立。 频繁的用户态和内核态拷贝，性能开销较大。 需要对文档配置文档表进行结点，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; /* 文档配置文档 */
shortevents; /* 关心的事件 */
short revents; /* 实际返回的事件 */
};
从下面的结构能看出，fd很明显就是指文档配置文档，也就是当客户端相连上来后，fd会将生成的文档配置文档保存到这儿；而events则是指用户想关注的事件；revents则是指实际返回的事件，是由控制系统内核填充并返回，如果当前的fd文档配置文档有状态变化，则revents的值就会有相应的变化。
events事件条目如下：
revents事件条目如下：
从条目中能看出，revents是包含events的。接下来结合示例上看呵呵：
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数学模型要好用一些，去掉了一些限制，但是仍然避免不了如下的问题：
用户态和内核态仍需要频繁切换，因为revents的赋值是在内核态进行的，然后再推送到用户态，和select类似于，整体开销较大。 仍需要结点数组，时间复杂度为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 epolls 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都指接收缓冲区：
buffer由空变为非空，意即有数据进来的这时候，此过程会触发通知。 buffer原本有些数据，这这时候又有新数据进来的这时候，数据变多，此过程会触发通知。 buffer中有数据，此时用户对操作的fd注册EPOLL_CTL_MOD事件的这时候，会触发通知。针对写操作，也就是当前fd处于EPOLLOUT模式下，即可写。此时意味着缓冲区能写了，以下buffer都指发送缓冲区：
buffer满了，这这时候发送出去一些数据，数据变少，此过程会触发通知。 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高性能的根本就是，其高效的文档配置文档处理方式加上颇具特性边的缘触发处理模式，以极少的内核态和用户态的切换，实现了真正意义上的高并发。
