《Reids 设计与实现》第九章事件

最新推荐文章于 2024-02-13 19:41:50 发布

313YPHU3

最新推荐文章于 2024-02-13 19:41:50 发布

阅读量521

点赞数

分类专栏：《Redis 设计与实现》文章标签： Redis

本文链接：https://blog.csdn.net/qq_45593575/article/details/121970929

版权

《Redis 设计与实现》专栏收录该内容

20 篇文章 2 订阅

订阅专栏

《Reids 设计与实现》第九章事件

文章目录

《Reids 设计与实现》第九章事件
一、简介
二、文件事件
三、时间事件
四、事件的调度与执行
五、重点回顾

一、简介

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

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

二、文件事件

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

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

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

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

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

在这里插入图片描述

文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现

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

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

在这里插入图片描述

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

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

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

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

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

在这里插入图片描述

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

3.事件的类型

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

当套接字变得可读时，或者有新的可应答套接字出现时，套接字产生 AE_READABLE 事件
当套接字变得可写时，套接字产生 AE_WRITABLE 事件

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

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

4.API

ae.c/aeCreatFileEvent 函数接受一个套接字描述符、一个事件类型，以及一个事件处理器作为参数，将给定套接字的给定事件加入到 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 函数返回 I/O 多路复用程序底层所使用的 I/O 多路复用函数库的名称：返回 “epoll” 表示底层为 epoll 函数库，返回 “select” 表示底层为 select 函数库，诸如此类

5.文件事件的处理器

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

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

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

连接应答处理器

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 事件，引发命令请求处理器执行，并执行相应的套接字读入操作

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

命令回复处理器

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

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

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

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

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

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

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

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

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

图 12-7 总结了上面描述的整个通信过程，以及通信时用到的事件处理器

在这里插入图片描述

三、时间事件

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

定时事件：让一段程序在执行的时间之后执行一次。比如说，让程序 X 在当前时间的 30 毫秒之后执行一次
周期性时间：让一段程序每隔指定时间就执行一次。比如说，让程序 Y 每隔 30 毫秒就执行一次

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

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

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

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

1.实现

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

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

在这里插入图片描述

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

2.API

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

ae.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)

3.时间时间应用实例：serverCron 函数

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

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

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

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

四、事件的调度与执行

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

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

def aeProcessEvents():
	#获取到达时间离当前时间最接近的时间事件
	time_event = aeSearchNearestTimer)

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

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

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

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

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

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

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

def main():
	#初始化服务器
	init_server()

	#持续处理事件，直到服务器关闭为止
	while server_is_not_shutdown():
		aeProcessEvents()

	#服务器关闭，执行清理操作
	clean_server()

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

在这里插入图片描述

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

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