redis的事件机制

Redis服务器是一个事件驱动程序（单Reactor单线程模型），服务器需要处理以下两类事件：

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

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

文件事件

Redis基于Reactor模式开发了自己的网络事件处理器:这个处理器

被称为文件事件处理器(file event handler):

• 文件事件处理器使用I/O多路复用(multiplexing)程序来同时监听 多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件 处理器。
• 当被监听的套接字准备好执行连接应答(accept)、读取 (read)、写入(write)、关闭(close)等操作时，与操作相对应的文 件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事 件处理器来处理这些事件。

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

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

下图展示了文件事件处理器的四个组成部分，它们分别是套接 字、I/O多路复用程序、文件事件分派器(dispatcher)，以及事件处理器。

2. I/O多路复用程序的实现

Redis的I/O多路复用程序的所有功能都是通过包装常见的select、epoll、evport和kqueue这些I/O多路复用西数库米实现的，每个I/O多路复用两数库在Redis源码中都对应一个单独的文件，比如ae_select.c、ae_epoll.c、 ae_ kqueue.c， 诸如此类。
因为Redis为每个IO多路复用两数库都实现了相同的API，所以IO多路复用程序的底层实现是可以互换的，如图所示：

3. 事件的类型

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

• 当套接字变得可读时（客户端对套接字执行write操作，或者执行close操作），或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行connect操作），套接宇产生AF READABLE事件。
• 当套接字变得可写时（客户端对套接宇执行read操作），套接字产生AE WRITABLE事件。IO多路复用程序允许服务器同时监听套接字的AE READABLE事件和AE_WRITABLE事件，如果一个套接字同时产生了这两种事件，那么文件事件分派器会优先处理AE_READABLE事件，等到AE_ READABLE事件处理完之后，才处理AE_ WRITABLE事件。
  这也就是说，如果一个套接字又可读又可写的话，那么服务器将先读套接字，后写套接字。

4. 文件事件的处理器

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

• 为了对连接服务器的各个客户端进行应答，服务器要为监听套接字关联连接应答处理器。
• 为了接收客户端传来的命令请求，服务器要为客户端套接字关联命令请求处理器。
• 为了向客户端返回命令的执行结果，服务器要为客户端套接字关联命令回复处理器。
• 当主服务器和从服务器进行复制操作时，主从服务器都需要关联特别为复制功能编写的复制处理器。

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

一次完整的客户端与服务器连接事件示例

让我们来追踪一次Redis客户端与服务器进行连接并发送命令的整 个过程，看看在过程中会产生什么事件，而这些事件又是如何被处理 的。

假设一个Redis服务器正在运作，那么这个服务器的监听套接字的 AE_READABLE事件应该正处于监听状态之下，而该事件所对应的处理 器为连接应答处理器。

如果这时有一个Redis客户端向服务器发起连接，那么监听套接字 将产生AE_READABLE事件，触发连接应答处理器执行。处理器会对客 户端的连接请求进行应答，然后创建客户端套接字，以及客户端状态， 并将客户端套接字的AE_READABLE事件与命令请求处理器进行关联， 使得客户端可以向主服务器发送命令请求。

之后，假设客户端向主服务器发送一个命令请求，那么客户端套接字将产生AE_READABLE事件，引发命令请求处理器执行，处理器读取 客户端的命令内容，然后传给相关程序去执行。

执行命令将产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的AE_WRITABLE事件与命令回复处理器进行关联。当客户端尝试读取命令回复的时候，客户端套接字将产生 AE_WRITABLE事件，触发命令回复处理器执行，当命令回复处理器将命令回复全部写入到套接字之后，服务器就会解除客户端套接字的 AE_WRITABLE事件与命令回复处理器之间的关联。

时间事件

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

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

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

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

• id:服务器为时间事件创建的全局唯一ID(标识号)。ID号按从小到大的顺序递增，新事件的ID号比旧事件的ID号要大。
• when:毫秒精度的UNIX时间戳，记录了时间事件的到达(arrive)时间。
• timeProc:时间事件处理器，一个函数。当时间事件到达时，服务器就会调用相应的处理器来处理事件。

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

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

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

目前版本的Redis只使用周期性事件，而没有使用定时事件。

1. 实现

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

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

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

无序链表并不影响时间事件处理器的性能

在目前版本中，正常模式下的Redis服务器只使用serverCron一个时间事件，而在benchmark模式下，服务器也只使用两个时间事件。在这种情况下，服务器几乎是将无序链表退化成一个指针来使 用，所以使用无序链表来保存时间事件，并不影响事件执行的性能。

事件的调度与执行

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

以下是事件的调度和执行规则：

1）aeApiPoll函数的最大阻塞时间由到达时间最接近当前时间的时间事件决定，这个方法既可以避免服务器对时间事件进行频繁的轮（忙等待），也可以确保aeApiPoll函数不会阻塞过长时间。
2）因为文件事件是随机出现的，如果等待并处理完一次文件事件之后，仍未有任何时间事件到达，那么服务器将再次等待并处理文件事件。随着文件事件的不断执行，时间会逐渐向时间事件所设置的到达时间逼近，并最终水到到达时间，这时服务器就可以开始处理到达的时间事件了。
3）对文件事件和时间事件的处理都是同步、有序、原子地执行的，服务器不会中途中断事件处理，也不会对事件进行抢占，因此，不管是文件事件的处理器，还是时间事件的处理器，它们都会尽可地减少程序的阻空时间，并在有需要时主动让出执行权，从而降低造成事件饥饿的可能性。比如说，在命令回复处理器将一个命令回复写入到客户端套接宇时，如果写入字节数超过了一个预设常量的话，命令回复处理器就会主动里break跳出写入循环，将余下的数据留到下次再写：另外，时间事件也会将非常耗时的持久化操作放到子线程或者子进程执行。
4）因为时间手件在文件事件之后执行，并且事件之间不会出现抢占，所以时间事件的实际处理时间，通常会比时间事件设定的到达时间稍晩一些。