文件事件、时间事件、事件调度与执行

概述文件事件文件事件处理器的构成(重要!!!)事件类型(读事件 和 写事件)文件事件相关APII/O多路复用程序的实现(重要!!!)文件事件处理器(重要!!!)连接应答处理器命令请求处理器命令回复处理器一次完整的客户端与服务器连接事件示例(重要!!!)时间事件时间事件的实现(重要!!!)无序链表 并不影响 时间事件处理器的性能事件时间相关APIserverCron函数事件的调度与执行

概述

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

文件事件（file event）：Redis服务器 通过 套接字 与 客户端（或者其他Redis服务器）进行连接，而 文件事件 就是 服务器 对套接字操作 的 抽象。服务器 与 客户端（或者其他服务器） 的 通信 会产生 相应的 文件事件，而 服务器 则通过 监听并处理 这些事件 来完成 一系列网络通信操作时间事件（time event）：Redis服务器中的一些操作（比如serverCron函数）需要在给定的时间点执行，而 时间事件 就是 服务器对这类定时操作的抽象

文件事件

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

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

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

文件事件处理器的构成(重要!!!)

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

文件事件 是对 套接字操作 的 抽象，每当 一个套接字 准备好 执行 连接应答（accept）、写入、读取、关闭等操作时，就会产生一个文件事件

因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现

I/O多路复用程序 负责监听 多个套接字，并向 文件事件分派器 传送 那些 产生了事件 的 套接字

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

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

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

事件类型(读事件 和 写事件)

I/O多路复用程序 可以监听 多个套接字 的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件

这两类事件 和 套接字操作之间的对应关系如下：

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

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

也就是说，如果一个套接字又可读又可写的话，那么服务器将先读套接字，后写套接字

文件事件相关API

就是上面说到的不同函数库实现的相同API

ae.c/aeCreateFileEvent函数 接受 一个套接字描述符、一个事件类型，以及一个事件处理器 作为参数

将 给定套接字 的 给定事件 加入到 I/O多路复用程序 的 监听范围之内，并对 事件 和 事件处理器 进行关联

ae.c/aeDeleteFileEvent函数 接受 一个套接字描述符和一个监听事件类型作为参数，让 I/O多路复用程序取消对 给定套接字 的 给定事件 的监听，并取消 事件 和 事件处理器 之间的关联

ae.c/aeGetFileEvents函数 接受 一个套接字描述符，返回 该套接字 正在被监听 的 事件类型：

如果套接字没有任何事件被监听，那么函数返回AE_NONE如果套接字的读事件正在被监听，那么函数返回AE_READABLE如果套接字的写事件正在被监听，那么函数返回AE_WRITABLE如果套接字的读事件和写事件正在被监听，那么函数返回AE_READABLE|AE_WRITABLE

ae.c/aeWait函数 接受 一个套接字描述符、一个事件类型和一个毫秒数为参数，在 给定的时间内阻塞并等待套接字 的 给定类型事件产生，当事件成功产生，或者等待超时之后，函数返回

ae.c/aeApiPoll函数 接受 一个sys/time.h/struct timeval结构为参数，并在指定的时间內，阻塞并等待所有被aeCreateFileEvent函数 设置为 监听状态的套接字 产生 文件事件，当有至少一个事件产生，或者等待超时后，函数返回

ae.c/aeProcessEvents函数 是 文件事件分派器，它先调用aeApiPoll函数 来等待 事件产生，然后遍历所有已产生的事件，并调用相应的事件处理器来处理这些事件

ae.c/aeGetApiName函数 返回 I/O多路复用程序底层 所使用的 I/O多路复用函数库的名称：返回"epoll"表示底层为epoll函数库，返回"select"表示底层为select函数库，诸如此类

I/O多路复用程序的实现(重要!!!)

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多路复用程序的底层实现

/* Include the best multiplexing layer supported by this system.* The following should be ordered by performances, descending. */# 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

文件事件处理器(重要!!!)

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

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

连接应答处理器

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

当Redis服务器进行初始化的时候，程序 会将 这个连接应答处理器 和 服务器监听套接字的AE_READABLE事件关联起来

当有客户端用sys/socket.h/connect函数 连接 服务器监听套接字 的 时候，套接字就会产生AE_READABLE事件，引发连接应答处理器执行，并执行相应的套接字应答操作

命令请求处理器

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

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

命令回复处理器

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

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

一次完整的客户端与服务器连接事件示例(重要!!!)

时间事件

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

定时事件：让 一段程序 在指定的时间之后 执行一次周期性事件：让 一段程序 每隔指定时间 就执行一次

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

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

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

如果事件处理器返回ae.h/AE_NOMORE，那么 这个事件 为 定时事件：该事件在达到一次之后就会被删除，之后不再到达如果事件处理器返回一个非AE_NOMORE的整数值，那么 这个事件 为 周期性事件：当一个时间事件到达之后，服务器会根据事件处理器返回的值，对 时间事件的when属性 进行更新，让 这个事件 在一段时间之后 再次到达，并以这种方式一直更新并运行下去

比如说，如果一个时间事件的处理器返回整数值30，那么服务器应该对这个时间事件进行更新，让这个事件在30毫秒之后再次到达

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

时间事件的实现(重要!!!)

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

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

注意，保存 时间事件 的 链表 为 无序链表，指的不是链表不按ID排序，而是说，该链表不按when属性的大小排序

正因为链表没有按when属性进行排序，所以当时间事件执行器运行的时候，它必须遍历链表中的所有时间事件，这样才能确保服务器中所有已到达的时间事件都会被处理

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

在目前版本中，正常模式下的Redis服务器只使用serverCron一个时间事件，而在benchmark模式下，服务器也只使用两个时间事件

在这种情况下，服务器几乎是将无序链表退化成一个指针来使用，所以使用无序链表来保存时间事件，并不影响事件执行的性能

事件时间相关API

ae.c/aeCreateTimeEvent函数 接受 一个毫秒数milliseconds 和 一个时间事件处理器proc作为参数，将 一个 新的时间事件 添加到 服务器，这个新的时间事件 将在 当前时间 的 milliseconds毫秒 之后到达，而事件的处理器为procae.c/aeDeleteFileEvent函数 接受 一个时间事件ID作为参数，然后 从服务器中 删除 该ID所 对应的 时间事件ae.c/aeSearchNearestTimer函数 返回 到达时间 距离 当前时间 最接近的 那个时间事件ae.c/processTimeEvents函数 是 时间事件 的 执行器，这个函数 会遍历 所有 已到达 的 时间事件，并 调用 这些事件 的 处理器。已到达指的是，时间事件的when属性记录的UNIX时间戳 等于或小于 当前时间的UNIX时间戳

processTimeEvents函数的定义可以用以下伪代码来描述：

def processTimeEvents():# 遍历服务器中的所有时间事件for time_event in all_time_event():# 检查事件是否已经到达if time_event.when <= unix_ts_now():# 事件已到达# 执行事件处理器，并获取返回值retval = time_event.timeProc()# 如果这是一个定时事件if retval == AE_NOMORE:# 那么将该事件从服务器中删除delete_time_event_from_server(time_event)# 如果这是一个周期性事件else:# 那么按照事件处理器的返回值更新时间事件的 when 属性# 让这个事件在指定的时间之后再次到达update_when(time_event, retval)

serverCron函数

持续运行的Redis服务器需要定期对自身的资源和状态进行检查和调整，从而确保服务器可以长期、稳定地运行，这些定期操作由redis.c/serverCron函数负责执行，它的主要工作包括：

更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等清理数据库中的过期键值对关闭和清理连接失效的客户端尝试进行AOF或RDB持久化操作如果服务器是主服务器，那么对从服务器进行定期同步如果处于集群模式，对集群进行定期同步和连接测试

Redis服务器以周期性事件的方式来运行serverCron函数，在服务器运行期间，每隔一段时间，serverCron就会执行一次，直到服务器关闭为止

在Redis2.6版本，服务器默认规定serverCron每秒运行10次，平均每间隔100毫秒运行一次

从Redis2.8开始，用户可以通过修改hz选项来调整serverCron的每秒执行次数，具体信息请参考示例配置文件redis.conf关于hz选项的说明

阅读参考：

Redis-serverCron函数

事件的调度与执行

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

事件的调度和执行由ae.c/aeProcessEvents函数负责，以下是该函数的伪代码表示：

def aeProcessEvents():# 获取到达时间离当前时间最接近的时间事件time_event = aeSearchNearestTimer()# 计算最接近的时间事件距离到达还有多少毫秒remaind_ms = time_event.when - unix_ts_now()# 如果事件已到达，那么remaind_ms的值可能为负数，将它设定为0if remaind_ms < 0:remaind_ms = 0# 根据remaind_ms的值，创建timeval结构timeval = create_timeval_with_ms(remaind_ms)# 阻塞并等待文件事件产生，最大阻塞时间由传入的timeval结构决定# 如果remaind_ms的值为0，那么aeApiPoll调用之后马上返回，不阻塞aeApiPoll(timeval)# 处理所有已产生的文件事件processFileEvents()# 处理所有已到达的时间事件processTimeEvents()注意

processFileEvents这个函数它并不真正存在，在实际中，处理 已产生(的)文件事件 的代码 是直接写在aeProcessEvents函数里面的，这里为了方便讲述，才虚构了processFileEvents函数

将aeProcessEvents函数置于一个循环里面，加上初始化和清理函数，这就构成了Redis服务器的主函数，以下是该函数的伪代码表示：

def main():# 初始化服务器init_server()# 一直处理事件，直到服务器关闭为止while server_is_not_shutdown():aeProcessEvents()# 服务器关闭，执行清理操作clean_server()

从事件处理的角度来看，Redis服务器的运行流程可以用下面的流程图来概括

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

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

下面记录了一次完整的事件调度和执行过程

事件执行过程 凸显了 上面列举的 事件调度规则中 的 规则2、3、4：

因为时间事件尚未到达，所以在处理时间事件之前，服务器已经等待并处理了两次文件事件因为处理事件的过程中不会出现抢占，所以实际处理时间事件的时间比预定的100毫秒慢了30毫秒