Redis_15_Redis线程模型与事件

Posted 2022-09-24 毛奇志

文章目录

• 一、前言
• 二、文件事件
• 三、时间事件
• 四、事件的调度与执行（文件事件+时间事件）
• 五、尾声

一、前言

Redis服务器是一个事件驱动程序,服务器需要处理以下两类事件（文件事件+时间事件）：

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

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

二、文件事件

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

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

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

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

Redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。文件事件处理器 file event handler ，采用 IO 多路复用机制同时监听多个 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。文件事件处理器的结构包含 4 个部分：

多个 Socket
IO 多路复用程序
文件事件分派器
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

多个 Socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 Socket，会将 Socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。如下图：

对于上图的解释：

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

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

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

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

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

问题1：为什么redis是单线程的？
回答1：
底层原因：Redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。
业务原因一：redis采用了非阻塞的异步事件处理机制，没有必要用多线程
业务原因二：一般缓存数据都是内存操作 IO 时间不会太长，单线程可以避免线程上下文切换产生的代价。
业务原因三：redis确实是单线程，但是可以搭建多个redis实例构成redis集群。

问题2：Redis使用单线程，我们现在服务器都是多核的，那不是很浪费？
回答2：是的他是单线程的，但是，我们可以通过在单机开多个Redis实例。

问题3：redis单线程如何处理多个事件？
回答3：
第一，redis单线程，但是可以部署多个redis实例，实现redis集群。
第二，对于单个redis，它采用 IO 多路复用机制同时监听多个 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。

问题4：Redis使用单线程避免了上下文切换，什么是上下文切换？为什么上下文切换不安全？
回答4：好比你看一本英文书，你看到第十页发现有个单词不会读，你加了个书签，然后去查字典，过了一会你又回来继续从书签那里读，ok到目前为止没啥问题。如果是你一个人读肯定没啥问题，但是你去查的时候，别的小伙伴好奇你在看啥他就翻了一下你的书，然后溜了，哦豁，你再看的时候就发现书不是你看的那一页了。为啥会线程不安全，就是因为你一个人怎么看都没事，但是人多了换来换去的操作一本书数据就乱了。

三、时间事件

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

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

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

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

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

时间事件的底层实现：

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

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

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

四、事件的调度与执行（文件事件+时间事件）

因为服务器中同时存在文件事件和时间事件两种事件类型，所以服务器必须对两种事件进行调度，决定何时应该处理文件事件 ,何时又应该处理时间事件,以及花多少时间来理它们等等。给出伪代码（要和下面的图及其解释对应着看）：

def aeProcessEvents():
    # 获取到达时间离当前时间最接近的时间事件
    time_event = aeSearchNearestTimer()
    # 计算最接近的时间事件距离到达还有多少毫秒
    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，那么asApiPoll调用之后马上返回，不阻塞
    setApiPoll(timeval)
    # 处理所有已产生的文件事件
    processFileEvents()
    # 处理所有已产生的时间事件
    processTimeEvents()

从事件处理的角度来看，Redis服务器的运行流程如下：

对于上图解释：

1)aeApipo11函数的最大阻塞时间由到达时间最接近当前时间的时间事件决定,这个方法既可以避免服务器对时间事件进行频繁的轮询(忙等待),也可以确保 aeApiPo 函数不会阻寒过长时间。

2)因为文件事件是随机出现的,如果等待并处理完一次文件事件之后,仍未有任何时间事件到达,那么服务器将再次等待并处理文件事件。随着文件事件的不断执行,时间会逐渐向时间事件所设置时间逼近,并最终来到到达时间,这时服务器就可以开始处理到达的时间事件了。

3)对文件事件和时间事件的处理都是同步、有序、原子地执行的,服务器不会中途中断事件处理,也不会对事件进行抢占,因此,不管是文件事件的处理器,还是时间事件的处理器,它们都会尽可地减少程序的阻塞时间,并在有需要时主动让出执行权,从面降低造成事件饥饿的可能性。比如说,在命令回复处理器将一个命令回复写入到客户端套接字时,如果写入字节数超过了一个预设常量的话,命令回复处理器就会主动用 break跳出写入循环,将余下的数据留到下次再写;另外,时间事件也会将非常耗时的持久化操作放到子线程或者子进程执行。

4)因为时间事件在文件事件之后执行,并且事件之间不会出现抢占,所以时间事件的实际处理时间,通常会比时间事件设定的到达时间稍晚一些。

举例：一次完整的事件调度和执行过程

开始时间	结束时间	动作
0	10	创建一个在100毫秒到达的时间事件
11	30	等待文件事件
31	50	处理文件事件
51	85	等待文件事件
85	130	处理文件事件
131	150	执行时间事件

该表中记录的事件执行流程凸显了上面的时间调度规则2、3、4.
因为时间事件尚未到达，所以在处理时间事件之前，服务器已经等待并处理了两次文件事件。
因为处理事件的过程不会出现抢占，所以实际处理时间事件的时间比预定的100毫秒慢了30毫秒。

五、尾声

Redis线程模型与事件，完成了。