在linux没有实现epoll事件驱动机制之前,我们一般选择用选择或者调查等输入输出多路复用的方法来实现并发服务程序。在linux新的内核中,有了一种替换它的机制,就是epoll。
<强>选择的缺点:
1。单个进程能够监视的文件描述符的数量存在最大限制,通常是1024年,当然可以更改数量,但由于选择采用轮询的方式扫描文件描述符,文件描述符数量越多,性能越差;(在linux内核头文件中,有这样的定义:# define __FD_SETSIZE 1024)
2.内核/用户空间内存拷贝问题,选择需要复制大量的句柄数据结构,产生巨大的开销;
3.选择返回的是含有整个句柄的数组,应用程序需要遍历整个数组才能发现哪些句柄发生了事件;
4.选择的触发方式是水平触发,应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作,那么之后每次选择调用还是会将这些文件描述符通知进程。
相比选择模型,调查使用链表保存文件描述符,因此没有了监视文件数量的限制,但其他三个缺点依然存在。
假设我们的服务器需要支持100年万的并发连接,则在__FD_SETSIZE为1024年的情况下,则我们至少需要开辟1 k个进程才能实现100年万的并发连接。除了进程间上下文切换的时间消耗外,从内核/用户空间大量的无脑内存拷贝,数组轮询等,是系统难以承受的。因此,基于选择模型的服务器程序,要达10到万级别的并发访问,是一个很难完成的任务。
epoll IO多路复用模型实现机制
由于epoll的实现机制与选择/投票机制完全不同,上面所说的选择的缺点在epoll上不复存在。
设想一下如下场景:有100多万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻,通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发?
在选择/调查时代,服务器进程每次都把这100多万个连接告诉操作系统(从用户态复制句柄数据结构到内核态),让操作系统内核去查询这些套接字上是否有事件发生,轮询完后,再将句柄数据复制到用户态,让服务器应用程序轮询处理已发生的网络事件,这一过程资源消耗较大,因此,选择/调查一般只能处理几千的并发连接。
epoll的设计和实现与选择完全不同.epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现? B +树)。把原先的选择/调查调用分成了3个部分:
1)调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2)调用epoll_ctl向epoll对象中添加这100多万个连接的套接字
3)调用epoll_wait收集发生的事件的连接
如此一来,要实现上面说是的场景,只需要在进程启动时建立一个epoll对象,然后在需要的时候向这个epoll对象中添加或者删除连接,同时,epoll_wait的效率也非常高,因为调用epoll_wait时,并没有一股脑的向操作系统复制这100多万个连接的句柄数据,内核也不需要去遍历全部的连接。
epoll实现机制
当某一进程调用epoll_create方法时,Linux内核会创建一个eventpoll结构体,这个结构体中有两个成员与epoll的使用方式密切相关.eventpoll结构体如下所示:
每一个epoll对象都有一个独立的eventpoll结构体,用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中,如此,重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn,其中n为树的高度)。
而所有<强>添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系,也就是说,当相应的事件发生时会调用这个回调方法强。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中,对于每一个事件,都会建立一个epitem结构体,如下所示:
