Redis IO多路复用技术以及epoll实现原理

57 阅读 0 评论 38 点赞

我是靠谱客的博主平常小刺猬，最近开发中收集的这篇文章主要介绍Redis IO多路复用技术以及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的几大缺点： 
 
  1、每次调用select/poll，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大 
 
  2、同时每次调用select/poll都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大 
 
  3、针对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还有个回放的过程，低效了 
   ）