redis总结

I/O多路复用器监听套接字，并关联到相应的事件处理器上面，当被监听的套接字准备好执行链接时候，与之对应的文件事件处理器就会调用相应的事件处理器来处理事件

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

 如果没有I/O事件发生，我们的程序就会阻塞在select处。但是依然存在一个问题，我们从select那里仅仅知道了有I/O事件发生，
但却并不知道是哪几个流（可能一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出或者写入数据的流，对它们进行操作。
 但是，使用select，我们有O（n）无差别轮询复杂度，同时处理的流越多，每一次无差别的轮询时间就越长。

 总结：select/poll缺点如下：
每次调用select/poll都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大；
同时每次调用select/poll都需要在内核遍历传进来的所有fd，这个开销在fd很多时会很大；
select支持的文件描述符数量太小，默认1024；
select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知给进程；

  epoll的设计和实现与select完全不同。epoll是poll的一种优化，返回后不需要对所有的fd进行遍历，它在内核中维护了fd列表。select和poll是将这个内核列表维持在用户态，
然后复制到内核态。与select/poll不同，epoll不在是一个单独的调度系统，而是由epoll_create / epoll_ctl / epoll_wait三个系统组成，后面将会看到这样做的好处。epoll在2.6以后的内核才支持。
epoll通过在Linux内核中申请一个简易的文件系统（文件系统一般用什么数据结构？B+树）。把原先的select/poll调用分成三个部分。

调用epoll_create（）建立一个epoll对象（在epoll文件系统中为这个句柄对象分配资源）；
调用epoll_ctl向epoll对象中添加这100W个连接的套接字；
调用epoll_wait收集在这上面发生的事件连接。
        如此一来，要实现上面所说的的场景，只要在进程启动的时候创建一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除socket连接。同时，
epoll_wait的效率也是非常高的，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100W个连接的句柄数据，内核也不需要去遍历全部的连接。

 每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。
 这些事件都会挂在红黑树中，如此，重复添加的事件就可以通过红黑树高效标识出来（红黑树插入事件效率是lgn，其中n为树的高度）。

 而所有添加到epoll中的事件都会与设备（网卡）驱动程序建立回调关系，也就是说，
当相应的事件发生时，会调用这个回调方法。这个回调方法在内核中叫eppoll_callback，它会将发生的事件添加到rdlist双向链表中。