13.事件

作者: xMustang | 来源:发表于2020-02-23 15:28 被阅读0次

事件

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

文件事件。file event。

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

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

1. 文件事件

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

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

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

1.1 文件事件处理器的构成

下图是文件事件处理器的四个组成部分。

文件事件处理器的四个组成部分

文件事件处理器由四个部分组成：套接字、IO多路复用程序、文件事件分配器、事件处理器。

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

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

IO多路复用程序通过队列向文件事件分配器传送套接字

事件处理器就是一个个函数，它们定义了某个事件发生时，服务器应该执行的操作。

1.2 IO多路复用程序的实现

Redis的IO多路复用程序的所有功能都是通过包装常见的select、epoll、evport、kqueue这些IO多路复用函数库来实现的。

Redis中的每个IO多路复用程序库在Redis源码中都对应一个单独的文件，如ae_select.c、ae_epoll.c、ae_kqueue.c。

Redis为每个IO多路复用函数都实现了系统的API，所以IO多路复用程序的底层实现是可以互换的，程序会在编译时自动选择系统中性能最高的IO多路复用函数来作为Redis的IO多路复用程序的底层实现。

Redis的IO多路复用程序有多个IO多路复用库实现可选

1.3 事件的类型

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

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

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

1.4 API

ae.c/aeCreateFileEvent：接收一个套接字描述符、一个事件类型、一个事件处理器作为参数，将给定套接字的给定事件加入到IO多路复用程序的监听范围之内，并对事件、事件处理器进行关联。

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

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：返回IO多路复用程序底层所使用的IO多路复用函数库的名称，返回"epoll"表示底层为epoll函数库，返回"select"表示底层为select函数库，等等。

1.5 文件事件的处理器

Redis为文件事件编写了多个处理器。

1.5.1 连接应答处理器

networking.c/acceptTcpHandler是Redis的连接应答处理器。

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

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

服务器对客户端的连接请求进行应答

1.5.2 命令请求处理器

networking.c/readQueryFromClient是Redis的命令请求处理器。

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

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

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

服务器接收客户端发来的命令请求

1.5.3 命令回复处理器

networking.c/sendReplyToClient是Redis的命令回复处理器。

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

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

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

服务器向客户端发送命令回复

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

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

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

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

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

下图是上面的整个过程。

客户端和服务器的通信过程

2. 时间事件

Redis时间事件分为两类：

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

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

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

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

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

2.1 实现

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

无序链表的无序指的是节点不按when属性的大小排序，但是按照事件ID排序，新事件插入到链表的表头。

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

2.2 API

ae.c/aeCreateTimeEvent：接收一个毫秒数milliseconds和一个时间事件处理器proc作为参数，将一个新的时间事件添加到服务器，这个新的时间事件将在当前时间的milliseconds毫秒之后到达，而事件的处理器为proc。

ae.c/aeDeleteFileEvent：接收一个时间事件ID作为参数，然后从服务器中删除该ID所对应的时间事件。

ae.c/aeSearchNearestTimer：返回到达时间距离当前时间最接近的那个时间事件。

ae.c/processTimeEvents：时间事件的执行器。会遍历服务器中所有时间事件，找出所有已到达的时间事件，并调用这些事件的处理器。已到达指的是，时间事件的when属性记录的UNIX时间戳等于或小于当前时间的UNIX时间戳。

2.3 severCron函数

redis.c/serverCron主要工作包括：

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

服务器以周期性事件的方式来运行serverCron函数。

在Redis 2.6中，服务器默认规定serverCron平均每间隔100毫秒运行一次。从Redis 2.8开始，可以修改hz选项调整serverCron每秒执行次数。

3. 事件的调度与执行

服务器必须对文件事件、时间事件进行调度，决定何时应该处理文本事件，何时应该处理时间事件，以及花多少时间来处理它们等等。

事件的调度和执行由ae.c/aeProcessEvents函数负责。

以下是该函数的伪代码：

def aeProcessEvents();

    # 获取到达时间离当前时间最接近的时间事件。
    time_event = aeSearchNearesetTimer()

    # 计算最接近的时间事件距离到达还有多少毫秒
    remaind_ms = time_event.when - unix_ts_now()

    # 如果事件已到达，那么remaind_ms的值可能为负数，将它设定为0
    if remaind_ms < 0:
        remaind_ms = 0

    # 根据remaind_ms的值，创建timeval结构
    timeval = create_timeval_with_ms(remaind_ms)

    # 阻塞并等待文件事件发生，最大阻塞时间由传入的timeval结构决定
    # 如果remaind_ms的值为0，那么aeApiPoll调用之后马上返回，不阻塞
    aeApiPoll(timeval)

    # 处理所有已产生的文本事件
    processFileEvent()

    # 处理所有已到达的时间事件
    processTimeEvents()

以下是事件处理角度下的服务器运行流程。

事件处理角度下的服务器运行流程

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

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