文章目录

一、select和poll的缺点

  1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量(在linux内核头文件中，有这样的定义：​​#define __FD_SETSIZE 1024​​），但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差
  2. 内核和用户空间之间的内存拷贝问题，因为我们每次调用select和poll时。都会填写相应的位数组和其他的参数，select和poll需要复制大量的句柄数据结构到内核空间进行监听，监听完成后需要把发生事件句柄再拷贝到用户空间，会产生巨大的开销
  3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件。poll和select一样，都是轮询
  4. select和poll的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select和poll调用还是会将这些文件描述符通知进程。同一个事件，数据没有读完，会多次触发，效率低

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制（1024），但其他三个缺点依然存在

以select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，每个进程监听1024个连接，则我们至少需要开辟1k个进程才能实现100万的并发连接。一般来说，我们不会开启这么多进程或线程，除非是协程

除了进程间上下文切换的时间消耗外，从内核/用户空间大量的句柄结构内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到100万级别的并发访问，是一个很难完成的任务

二、epoll原理以及优势

epoll的实现机制与select/poll机制完全不同，它们的缺点在epoll上不复存在

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百个TCP连接是活跃的(事实上大部分场景都是这种情况)，如何实现这样的高并发？

在select / poll时代，服务器进程每次都把这100万个连接告诉操作系统（从用户态复制句柄数据结构到内核态），让操作系统内核去查询这些套接字上是否有事件发生，轮询完成后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此select/poll一般只能处理几千的并发连接

epoll的设计和实现与select完全不同，epoll通过在Linux内核中申请一个简易的文件系统（文件系统一般用B+树实现，磁盘IO消耗低，效率很高）

把原先的select/poll调用分成以下3个部分：

  • 调用epoll_create()建立一个epoll对象（在epoll文件系统中为这个句柄对象分配资源）
  • 调用epoll_ctl向epoll对象中添加这100万个连接的套接字，以红黑树的形式组织，增删查是select、poll、epoll对比总结_数据
  • 调用epoll_wait收集发生的事件的fd资源，发生事件的fd会从红黑树上拷贝到双向链表，用于返回给用户。用户拿到的就只有发生事件的文件描述符了

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除事件。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有向操作系统复制这100万个连接的句柄数据，因为前面通过epoll_ctl把感兴趣的句柄数据放在了内核的红黑树上。红黑树遍历是对数复杂度，内核也不需要去遍历全部的连接

epoll_create在内核上创建的eventpoll结构如下：

struct eventpoll{
  ....
  /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
  struct rb_root rbr;
  /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
  struct list_head rdlist;
  ....
};

select、poll、epoll对比总结_数据_02


​​javascript:void(0)​​

三、LT模式

水平触发：内核数据没被应用程序读完，就会一直上报

应用程序可以每次读一部分数据，没读完，下一次epoll_wait时内核还会上报。能够平均地处理每个socket上的读写事件，能够及时回到epoll_wait，让所有的socket都得到及时的处理，让客户端感觉服务器延时低

四、ET模式

边沿触发：从不可读到可读，或者从不可写到可写，这个状态的变化，内核只上报一次。如果应用程序不读完、不写完，就不会再触发了，数据会丢失

我们可能会认为ET模式只触发一次，效率高，LT模式就没有存在的价值，其实不是这样的

在极端情况下，epoll工作在ET模式下，一个socket上产生源源不断的数据，由于应用程序会循环读取这个socket上的数据，这就导致应用程序无法及时回到epoll_wait。假如此时又有其他请求到了，红黑树上有一些fd发生了事件被放到双向链表返回给应用程序，而此时应用程序还在读某个socket上的数据，无法及时回到epoll_wait，对于客户端来说，服务器就没有及时处理它的请求，客户端会觉得服务器的延时很高

五、muduo采用的是LT

  • 不会丢失数据或者消息：应用没有读取完数据，内核是会不断上报的
  • 低延迟处理：每次读数据只需要一次系统调用；照顾了多个连接的公平性，不会因为某个连接上的数据量过大而影响其他连接处理消息
  • 跨平台处理：像select一样可以跨平台使用。由于有的系统不支持ET模式，比如Unix系统是没有epoll的，但是有select / poll，这俩都是工作在LT模式

libevent是一个C语言写的网络库，底层也是事件驱动，统一事件源的epoll，采用的是ET模式，从压测的结果来看，在单线程下，muduo库和libevent库的性能差不多，在多线程情况下，muduo库的吞吐量大致可以达到libevent的近2倍

select、poll、epoll对比总结_句柄_03

select、poll、epoll对比总结_数据_04