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等等)。
select,poll,epoll都是IO多路复用的机制。I/O多路复用就通过一种机制,可以监视多个描述符,一旦某个描述符就绪,能够通知程序进行相应的操作。
select 的本质是采用 32 个整数的 32 位,即 32
32= 1024
来标识,fd值为 1-1024。当 fd 的值超过 1024 限制时,就必须修改 FD_SETSIZE 的大小。这个时候就可以标识32max
值范围的 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 以后的内核才支持。
epoll 有诸多优点:
select/poll的几大缺点:
相比 select模型,poll使用链表保存文件描述符,因此没有了监视文件数量的限制,但其他三个缺点依然存在。
由于 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个部分:
如此一来,要实现上面所说的场景,只需要在进程启动时建立一个 epoll 对象,然后在需要的时候向这个 epoll 对象中添加或者删除连接。同时,epoll_wait 的效率也非常高,因为调用 epoll_wait 时,并没有一股脑的向操作系统复制这100万个连接的句柄数据,内核也不需要去遍历全部的连接。
底层实现:
当某一进程调用 epoll_create 方法时,Linux 内核会创建一个 eventpoll 结构体,这个结构体中有两个成员与 epoll 的使用方式密切相关。eventpoll 结构体如下所示:
struct eventpoll {
//....
// 红黑树的根节点,这棵树中存储着所有添加到 epoll 中的需要监控的事件
struct rb_root rbr;
// 双链表中存放着将要通过 epoll_wait 返回给用户的满足条件的事件
struct list_head rdlist;
//....
}
每一个 epoll 对象都有一个独立的 eventpoll 结构体,用于存放通过 epoll_ctl 方法向 epoll 对象中添加进来的事件,这些事件都会挂载在用于存储上述的被监控 socket 的红黑树上,即上面源码的 rb_root。当你调用 epoll_create 时,就会在 epoll 注册的一个文件系统中创建一个 file 节点,这个 file 不是普通文件,它只服务于 epoll。epoll 在被内核初始化时(操作系统启动),同时会开辟出 epoll 自己的内核高速缓存区,用于安置每一个我们想监控的 socket,这些 socket 会以红黑树的形式保存在内核缓存里,红黑树的插入时间效率很高,对于高度为 n 的红黑树,查找、插入、删除的效率都是 lgn。如此重复添加的事件就可以通过红黑树高效的识别出来。
所有添加到 epoll 中的事件都会与设备(网卡)驱动程序**建立回调关系,也就是说当相应的事件发生时,会调用这个回调方法。这个回调方法在内核中叫 ep_poll_callback,它会将发生的事件添加到 rdlist 双链表中。
这个事件双链表是怎么维护的呢?当我们执行 epoll_ctl 时,除了把 socket 放到 epoll 文件系统里 file 对象对应的红黑树上之外,还会给内核中断处理程序注册一个回调函数**。告诉内核,如果这个句柄的中断到了,就把它放到准备就绪 list 链表里。所以,当一个 socket 上有数据到了,内核在把网卡上的数据 copy 到内核中,然后就把 socket 插入到准备就绪链表里了。由此可见,epoll 的基础就是回调。
epoll 的每一个事件都会包含一个 epitem 结构体,如下所示:
struct epitem {
// 红黑树节点
struct rb_node rbn;
// 双向链表节点
struct list_head rdllink;
// 事件句柄信息
struct epoll_filefd ffd;
// 指向所属的 eventpoll 对象
struct eventpoll *ep;
// 期待发生的事件类型
struct epoll_event event;
}
当调用 epoll_wait 检查是否有事件发生时,只需要检查 eventpoll 对象中的 rdlist 双链表中是否有 epitem 元素即可。如果 rdlist 不为空,则把发生的事件复制到用户态,同时将事件数量返回给用户。
综上所述,epoll 的执行过程:
注: epoll 独有的两种模式 LT 和 ET。无论是 LT 和 ET 模式,都适用于以上所说的流程。区别是,LT 模式下只要一个句柄上的事件一次没有处理完,会在以后调用 epoll_wait 时次次返回这个句柄。而ET模式仅在第一次返回。 关于 LT 和 ET 有一端描述,LT 和 ET 都是电子里面的术语,ET 是边缘触发,LT 是水平触发,一个表示只有在变化的边际触发,一个表示在某个阶段都会触发。 对于 epoll 而言,当一个 socket 句柄上有事件时,内核会把该句柄插入上面所说的准备就绪链表,这时我们调用 epoll_wait,会把准备就绪的 socket 拷贝到用户态内存,然后清空准备就绪链表。最后,epoll_wait 检查这些 socket,如果不是 ET 模式(就是LT模式的句柄了),并且这些 socket 上确实有未处理的事件时,又把该句柄放回到刚刚清空的准备就绪链表了。所以,非 ET 的句柄,只要它上面还有事件,epoll_wait 每次都会返回这个句柄。