深入Redis系列（五）Redis事件机制详解 IO多路复用、文件事件、时间事件、reactor模式

Redis服务器是一个事件驱动程序，服务器需要处理以下两类事件：

文件事件（file
event）：Redis服务器通过套接字与客户端（或者其他Redis服务器）进行连接，而文件事件就是服务器对套接字操作的抽象。服务器与客户端（或者其他服务器）的通信会产生相应的文件事件，而服务器则通过监听并处理这些事件来完成一系列网络通信操作。

时间事件（time event）：Redis服务器中的一些操作（比如
servercron函数）需要在给定的时间点执行，而时间事件就是服务器对这类定时操作的抽象。

01 Reactor模式

服务器编程中通常涉及三类socketfd，先简单定义一下：

connfd：客户端调用connect与服务端建立连接。

listenfd：服务端的监听套接字。

clientfd：服务端调用accept获取已连接客户端的套接字。

1.单线程阻塞模型

服务端只有一个线程，阻塞在accept函数上，等待客户端对listenfd成功建立连接。成功连接后处理返回的connfd，直到处理完后才关闭该connfd。

listenfd = socket(); // 初始化监听套接字bind();   // 绑定监听套接字和服务端地址listen(listenfd); // 监听while(1) {  int clientfd;  // 主线程阻塞在 accept 上直到返回已连接套接字  if ((clientfd=accept()) >= 0) {    // 如果返回 大于0，代表有新连接产生    dothing(clientfd);  // 处理请求    close(clientfd);    // 关闭连接  }}

特点：服务器端一次只能处理一个客户端连接。

2.多线程阻塞模型

服务端对每个新连接都单独启动一个线程去处理，主线程继续阻塞在accept上等待新连接。每当accept获取到新的connfd后，把这个connfd交给新的线程去处理。

listenfd = socket(); // 初始化监听套接字bind();   // 绑定监听套接字和服务端地址listen(listenfd); // 监听while(1) {  if ((clientfd=accept()) >= 0) {    // 如果返回 大于0，代表有新连接产生    // 启动新的线程去处理这个连接 主线程继续while循环等待新的连接    new_thread(clientfd);  }}

缺点：

系统最大线程数是有限的。对于突发的大量的客户端连接，不可能创建很多线程去处理连接。

线程的频繁切换极度浪费系统资源。

优化：可以使用线程池（动态和静态）

服务端首先创建一定数目的线程池备用，当新的客户连接来临后，利用负载均衡算法从线程池中取出一个线程去处理这个客户请求。

3.Reactor模式

Reactor模式又叫反应堆模式，是一种常见的高性能的服务器开发模式，著名的Netty、Redis等软件都使用到了Reactor模式。

Reacor模式是一种事件驱动机制，它逆转了事件处理的流程，不再是主动地等事件就绪，而是它提前注册好的回调函数，当有对应事件发生时就调用回调函数。
由陈硕所述，Reactor即为非阻塞IO + IO复用，单个Reactor的逻辑大致如下：

while(1) {    // 1.取得下次定时任务的时间，与设定time_out去较大值，即若下次定时任务时间超过1s就取下次定时任务时间为超时时间，否则取1s    int time_out = Max(1000, getNextTimerCallback());    // 2.调用Epoll等待事件发生（阻塞），超时时间为上述的time_out    int rt = epoll_wait(epfd, fds, ...., time_out);     if(rt < 0) {        // epoll调用失败。。    } else {        if (rt > 0) {            // 3. 以此处理发生IO时间的fd，调用其回调函数        }    }}

它的核心思想就是利用IO复用技术（select，poll，epoll等）来监听套接字上的读写事件，一旦某个fd上发生相应事件，就反过来处理该套接字上的回调函数。

4.单Reactor服务器模型

单Reactor服务器模型就是只有一个主线程运行Reactor。

整个线程有一个epoll句柄（epoll对象实例），用于管理所有的套接字。服务器将listenfd的读事件注册到epoll上，当epoll_wait返回时说明listenfd可读，即有新的连接建立。此时再调用accept函数获取新连接clientfd，然后将clientfd的读写事件也注册到这个epoll上，等待clientfd发生读写事件从epoll_wait返回后，再处理clientfd的事件。

// 单Reactor模型while(1) {    // 1.取得下次定时任务的时间，与设定time_out去较大值，即若下次定时任务时间超过1s就取下次定时任务时间为超时时间，否则取1s    int time_out = Max(1000, getNextTimerCallback());    // 2.调用Epoll等待事件发生，超时时间为上述的time_out    int rt = epoll_wait(epfd, fds, ...., time_out);     if(rt < 0) {        // epoll调用失败。。    } else {        if (rt > 0 ) {          foreach (fd in fds) {            if (是listenfd的可读事件) {            // 如果是连接事件              1. 获取连接 clientfd = accept();              2. 将clientfd的IO注册到epoll上            } else {            // 不是连接事件，那就是clientfd的读写事件，此时需要处理业务逻辑              dothing(fds[i]);            }          }        }    }}

对于clienfd发生读写事件后，需要进行业务逻辑处理。业务逻辑处理通常是耗时的，这会影响主线程的执行，也就是说主线程会等到 dothing(fds[i])
做完之后才进入下一次循环过程。

5.主从Reactor服务器模型

mainReactor由主线程运行，作用如下：通过epoll监听listenfd的可读事件，当可读事件发生后，调用accept函数获取clientfd，然后随机取出一个subReactor，将cliednfd的读写事件注册到这个subReactor的epoll上即可。也就是说，mainReactor只负责建立连接事件，不进行业务处理，也不关心已连接套接字的IO事件。

subReactor通常有多个，每个subReactor由一个线程来运行。subReactor的epoll中注册了clientfd的读写事件，当发生IO事件后，需要进行业务处理。

02 文件事件

Redis基于Reactor模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）：

1.文件事件处理器使用I/O多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。

2.当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器 以单线程方式
运行，但通过使用I/O多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与Redis服务器中其他同样以单线程方式运行的模块进行对接，这保持了Redis内部单线程设计的简单性。

1.文件事件处理器的构成

文件事件处理器由四部分组成：

_ 套接字 _

_ IO多路复用程序 _

_ 文件事件分派器（dispatcher） _

_ 事件处理器 _

文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答（accept）、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。I/O多路复用程序负责监听多个套接字，并向文件事件分派器传送那些产生了事件的套接字。

处理过程：尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都放到一个队列里面，然后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字。当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕），I/O多路复用程序才会继续向文件事件分派器传送下一个套接字。

文件事件分派器接收I/O多路复用程序传来的套接字，并根据套接字产生的事件的类型，调用相应的事件处理器。

服务器会为执行不同任务的套接字关联不同的事件处理器，这些处理器是一个个函数，它们定义了某个事件发生时，服务器应该执行的动作。

2. IO多路复用程序

Redis的I/O多路复用程序的所有功能都是通过包装常见的select、epoll、evport
和kqueue这些I/O多路复用函数库来实现的，每个I/O多路复用函数库在Redis源码中都对应一个单独的文件，比如
ae_select.c、ae_epoll.c、ae_kqueue.c，诸如此类。

因为Redis为每个I/O多路复用函数库都实现了相同的API，所以I/O多路复用程序的底层实现是可以互换的。

Redis在I/O多路复用程序的实现源码中用#include宏定义了相应的规则，程序会在编译时自动选择系统中性能最高的I/O多路复用函数库来作为Redis的I/O多路复用程序的底层实现：

#ifdef HAVE_EVPORT#include "ae_evport.c"#else    #ifdef HAVE_EPOLL    #include "ae_epoll.c"    #else        #ifdef HAVE_KQUEUE        #include "ae_kqueue.c"        #else        #include "ae_select.c"        #endif    #endif#endif

3.事件类型

I/O多路复用程序可以监听多个套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE
事件，这两类事件和套接字操作之间的对应关系如下：

a.当套接字变得可读时（客户端对套接字执行write操作，或者执行close操作）或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行connect操作），套接字产生AE_READABLE事件。

b.当套接字变得可写时（客户端对套接字执行read操作），套接字产生AE_WRITABLE事件。

I/O多路复用程序允许服务器同时监听套接字的读写事件，如果一个套接字同时产生了这两种事件，那么文件事件分派器会优先处理AE_READABLE事件，等到AE_READABLE事件处理完之后，才处理AE_WRITABLE事件。这也就是说，如果一个套接字又可读又可写的话，那么服务器将先读套接字，后写套接字。

4.文件事件处理器

Redis为文件事件编写了多个处理器，这些事件处理器分别用于实现不同的网络通信需求，比如说：

a.为了对连接服务器的各个客户端进行应答，服务器要为监听套接字关联连接应答处理器。

b.为了接收客户端传来的命令请求，服务器要为客户端套接字关联命令请求处理器。

c.为了向客户端返回命令的执行结果，服务器要为客户端套接字关联命令回复处理器。

d.当主服务器和从服务器进行复制操作时，主从服务器都需要关联特别为复制功能编写的复制处理器。

在这些事件处理器里面，服务器最常用的要数与客户端进行通信的连接应答处理器、命令请求处理器和命令回复处理器。

5.连接应答处理器

networking.c/acceptTcpHandler函数是Redis的连接应答处理器，这个处理器用于对连接服务器监听套接字的客户端进行应答，具体实现为sys/socket.h/accept函数的包装。

当Redis 服务器进行初始化的时候，程序会将这个连接应答处理器和服务器 监听套接字
的AE_READABLE事件关联起来，当有客户端用sys/socket.h/connect函数连接服务器监听套接字的时候，套接字就会产生AE_READABLE事件，引发连接应答处理器执行，并执行相应的套接字应答操作。

6.命令请求处理器

networking.c/readQueryFromClient
函数是Redis的命令请求处理器，这个处理器负责从套接字中读入客户端发送的命令请求内容，具体实现为unistd.h/read函数的包装。

当一个客户端通过连接应答处理器成功连接到服务器之后，服务器会将客户端套接字的AE_READABLE事件和命令请求处理器关联起来，当客户端向服务器发送命令请求的时候，套接字就会产生AE_READABLE事件，引发命令请求处理器执行，并执行相应的套接字读入操作。

在客户端连接服务器的整个过程中，服务器都会一直为客户端套接字的AE_READABLE事件关联命令请求处理器。

7.命令回复处理器

networking.c/sendReplyToClient函数是Redis的命令回复处理器，这个处理器负责将服务器执行命令后得到的命令回复通过套接字返回给客户端，具体实现为unistd.h/write函数的包装。

当服务器有命令回复需要传送给客户端的时候，服务器会将客户端套接字的AE_WRITABLE
事件和命令回复处理器关联起来，当客户端准备好接收服务器传回的命令回复时，就会产生AE_WRITABLE事件，引发命令回复处理器执行，并执行相应的套接字写入操作。

当命令回复发送完毕之后，服务器就会解除命令回复处理器与客户端套接字的AE_WRITABLE事件之间的关联。

03 时间事件

Redis 的时间事件分为以下两类：

1.定时事件：让一段程序在指定的时间之后执行一次。比如说，让程序X在当前时间的30毫秒之后执行一次。

2.周期性事件：让一段程序每隔指定时间就执行一次。比如说，让程序Y每隔30毫秒就执行一次。

一个时间事件主要由以下三个属性组成：

id：服务器为时间事件创建的全局唯一ID（标识号）。ID号按从小到大的顺序递增，新事件的ID号比旧事件的ID号要大。

when：毫秒精度的UNIX时间戳，记录了时间事件的到达（arrive）时间。

timeProc：时间事件处理器，一个函数。当时间事件到达时，服务器就会调用相应的处理器来处理事件。

一个时间事件是定时事件还是周期性事件取决于时间事件处理器的返回值：

1.如果事件处理器返回 ae.h/AE_NOMORE，那么这个事件为定时事件：该事件在达到一次之后就会被删除，之后不再到达。

2.如果事件处理器返回一个非 AE_NOMORE 的整数值，那么这个事件为周期性时间：当一个时间事件到达之后，服务器会根据事件处理器返回的值，对时间事件的
when
属性进行更新，让这个事件在一段时间之后再次到达，并以这种方式一直更新并运行下去。比如说，如果一个时间事件的处理器返回整数值30，那么服务器应该对这个时间事件进行更新，让这个事件在30毫秒之后再次到达。

如何实现

服务器将所有时间事件都放在一个无序链表中，每当时间事件执行器运行时，它就遍历整个链表，查找所有已到达的时间事件，并调用相应的事件处理器。

下图展示了一个保存时间事件的链表的例子，链表中包含了三个不同的时间事件：因为新的时间事件总是插入到链表的表头，所以三个时间事件分别按ID逆序排序，表头事件的ID为3，中间事件的ID为2，表尾事件的ID为1。

注意，我们说保存时间事件的链表为无序链表，指的不是链表不按ID排序，而是说，该链表不按when属性的大小排序。正因为链表没有按when属性进行排序，所以当时间事件执行器运行的时候，它必须遍历链表中的所有时间事件，这样才能确保服务器中所有已到达的时间事件都会被处理。

事件的调度与执行

因为服务器中同时存在文件事件和时间事件两种事件类型，所以服务器必须对这两种事件进行调度，决定何时应该处理文件事件，何时又应该处理时间事件，以及花多少时间来处理它们等等。