redis epoll 原理梗概

redis 是一个单线程却性能很是好的内存数据库， 主要用来做为缓存系统。 redis 采用网络IO多路复用技术来保证在多链接的时候， 系统的高吞吐量。
为何 Redis 中要使用 I/O 多路复用这种技术呢？
首先，Redis 是跑在单线程中的，全部的操做都是按照顺序线性执行的，可是因为读写操做等待用户输入或输出都是阻塞的，因此 I/O 操做在通常状况下每每不能直接返回，这会致使某一文件的 I/O 阻塞致使整个进程没法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。
redis的io模型主要是基于epoll实现的，不过它也提供了 select和kqueue的实现，默认采用epoll。
那么epoll究竟是个什么东西呢？ 其实只是众多i/o多路复用技术当中的一种而已，可是相比其余io多路复用技术(select, poll等等)，epoll有诸多优势：
　　1. epoll 没有最大并发链接的限制，上限是最大能够打开文件的数目，这个数字通常远大于 2048, 通常来讲这个数目和系统内存关系很大  ，具体数目能够 cat /proc/sys/fs/file-max 察看。
　　2. 效率提高， Epoll 最大的优势就在于它只管你“活跃”的链接 ，而跟链接总数无关，所以在实际的网络环境中， Epoll 的效率就会远远高于 select 和 poll 。
　　3. 内存拷贝， Epoll 在这点上使用了“共享内存 ”，这个内存拷贝也省略了。

epoll与select/poll的区别
     select，poll，epoll都是IO多路复用的机制。I/O多路复用就经过一种机制，能够监视多个描述符，一旦某个描述符就绪，可以通知程序进行相应的操做。
     select的本质是采用32个整数的32位，即32*32= 1024来标识，fd值为1-1024。当fd的值超过1024限制时，就必须修改FD_SETSIZE的大小。这个时候就能够标识32*max值范围的fd。
     poll与select不一样，经过一个pollfd数组向内核传递须要关注的事件，故没有描述符个数的限制，pollfd中的events字段和revents分别用于标示关注的事件和发生的事件，故pollfd数组只须要被初始化一次。
     epoll仍是poll的一种优化，返回后不须要对全部的fd进行遍历，在内核中维持了fd的列表。select和poll是将这个内核列表维持在用户态，而后传递到内核中。与poll/select不一样，epoll再也不是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样作的好处。epoll在2.6之后的内核才支持。
select/poll的几大缺点：
一、每次调用select/poll，都须要把fd集合从用户态拷贝到内核态，这个开销在fd不少时会很大
二、同时每次调用select/poll都须要在内核遍历传递进来的全部fd，这个开销在fd不少时也很大
三、针对select支持的文件描述符数量过小了，默认是1024
4.select返回的是含有整个句柄的数组，应用程序须要遍历整个数组才能发现哪些句柄发生了事件；
5.select的触发方式是水平触发，应用程序若是没有完成对一个已经就绪的文件描述符进行IO操做，那么以后每次select调用仍是会将这些文件描述符通知进程。
相比select模型，poll使用链表保存文件描述符，所以没有了监视文件数量的限制，但其余三个缺点依然存在。

epoll IO多路复用模型实现机制
因为epoll的实现机制与select/poll机制彻底不一样，上面所说的 select的缺点在epoll上不复存在。
epoll没有这个限制，它所支持的FD上限是最大能够打开文件的数目，这个数字通常远大于2048,举个例子,在1GB内存的机器上大约是10万左右
设想一下以下场景：有100万个客户端同时与一个服务器进程保持着TCP链接。而每一时刻，一般只有几百上千个TCP链接是活跃的(事实上大部分场景都是这种状况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这100万个链接告诉操做系统(从用户态复制句柄数据结构到内核态)，让操做系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，所以，select/poll通常只能处理几千的并发链接。
若是没有I/O事件产生，咱们的程序就会阻塞在select处。可是依然有个问题，咱们从select那里仅仅知道了，有I/O事件发生了，但却并不知道是那几个流（可能有一个，多个，甚至所有），咱们只能无差异轮询全部流，找出能读出数据，或者写入数据的流，对他们进行操做。
可是使用select，咱们有O(n)的无差异轮询复杂度，同时处理的流越多，每一次无差异轮询时间就越长
epoll的设计和实现与select彻底不一样。epoll经过在Linux内核中申请一个简易的文件系统(文件系统通常用什么数据结构实现？B+树)。把原先的select/poll调用分红了3个部分：
1）调用epoll_create()创建一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个链接的套接字
3）调用epoll_wait收集发生的事件的链接
如此一来，要实现上面说是的场景，只须要在进程启动时创建一个epoll对象，而后在须要的时候向这个epoll对象中添加或者删除链接。同时，epoll_wait的效率也很是高，由于调用epoll_wait时，并无一股脑的向操做系统复制这100万个链接的句柄数据，内核也不须要去遍历所有的链接。

底层实现：
当某一进程调用epoll_create方法时，Linux内核会建立一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体以下所示：

每个epoll对象都有一个独立的eventpoll结构体，用于存放经过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就能够经过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。
而全部添加到epoll中的事件都会与设备(网卡)驱动程序创建回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每个事件，都会创建一个epitem结构体，以下所示：

当调用epoll_wait检查是否有事件发生时，只须要检查eventpoll对象中的rdlist双链表中是否有epitem元素便可。若是rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
优点：
1. 不用重复传递。咱们调用epoll_wait时就至关于以往调用select/poll，可是这时却不用传递socket句柄给内核，由于内核已经在epoll_ctl中拿到了要监控的句柄列表。
 2. 在内核里，一切皆文件。因此，epoll向内核注册了一个文件系统，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个虚拟的epoll文件系统里建立一个file结点。固然这个file不是普通文件，它只服务于epoll。
epoll在被内核初始化时（操做系统启动），同时会开辟出epoll本身的内核高速cache区，用于安置每个咱们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是创建连续的物理内存页，而后在之上创建slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。
 3. 极其高效的缘由：
这是因为咱们在调用epoll_create时，内核除了帮咱们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储之后epoll_ctl传来的socket外，还会再创建一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据便可。有数据就返回，没有数据就sleep，等到timeout时间到后即便链表没数据也返回。因此，epoll_wait很是高效。
  
    这个准备就绪list链表是怎么维护的呢？当咱们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上以外，还会给内核中断处理程序注册一个回调函数，告诉内核，若是这个句柄的中断到了，就把它放到准备就绪list链表里。因此，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。（注：好好理解这句话！）
从上面这句能够看出，epoll的基础就是回调呀！ 
 
    如此，一颗红黑树，一张准备就绪句柄链表，少许的内核cache，就帮咱们解决了大并发下的socket处理问题。执行epoll_create时，建立了红黑树和就绪链表，执行epoll_ctl时，若是增长socket句柄，则检查在红黑树中是否存在，存在当即返回，不存在则添加到树干上，而后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时马上返回准备就绪链表里的数据便可。

    最后看看epoll独有的两种模式LT和ET。不管是LT和ET模式，都适用于以上所说的流程。区别是，LT模式下，只要一个句柄上的事件一次没有处理完，会在之后调用epoll_wait时次次返回这个句柄，而ET模式仅在第一次返回。
 
    关于LT，ET，有一端描述，LT和ET都是电子里面的术语，ET是边缘触发，LT是水平触发，一个表示只有在变化的边际触发，一个表示在某个阶段都会触发。
LT, ET这件事怎么作到的呢？当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时咱们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，而后清空准备就绪list链表，最后，epoll_wait干了件事，就是检查这些socket，若是不是ET模式（就是LT模式的句柄了），而且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表了。因此，非ET的句柄，只要它上面还有事件，epoll_wait每次都会返回这个句柄。（从上面这段，能够看出，LT还有个回放的过程，低效了）

---------------------
做者：wxy941011
来源：CSDN
原文：https://blog.csdn.net/wxy941011/article/details/80274233
版权声明：本文为博主原创文章，转载请附上博文连接！