redis的事件处理机制
redis是单进程,单线程模型,与nginx的多进程不同,与golang的多协程也不同,“工作的工人”那么少,可那么为什么redis能这么快呢?
epoll多路复用
这里重点要说的就是redis的IO编程模型,首先了解下
为什么要有多路复用呢?
如果没有多路复用,一个线程只能监听一个端口的一个连接,这样这个效率比较低。当然我们有几种办法可以破除这个,一个是使用多线程模型,我们还是监听一个端口,但是一个请求进来,我们为其创建一个线程。但是这种消耗是比较大的。所以我们一直想办法,有没有办法一个线程监听多个端口,或者多个一个端口的多个连接(fd)。
这里再说说fd, 文件描述符(file descriptor)是内核为了高效管理已被打开的文件所创建的索引,其是一个非负整数(通常是小整数),用于指代被打开的文件,所有执行I/O操作(包括网络socket操作)的系统调用都通过文件描述符。每个连接请求上来,都会创建一个连接套接字,一个连接使用一个连接套接字。
对于监听端口,我们会有一个监听套接字,对应监听fd。我们所有的监听业务都是从监听这个套接字开始的。
那么如果我一个程序能同时监听多个连接套接字,是不是就很赞了。是的,这就是linux的io多路复用逻辑。但是这么多连接套接字,传递数据等是断断续续的,A连接接收一个包,B连接再接收一个包,A连接再接收一个包,B连接再接收一个包....如果我等着A连接把包都接收完再处理B,那效率是非常慢的。所以,这里我们就需要有一个通知机制,让有收到包的时候通知下处理线程。
linux的IO多路复用逻辑主要有三种:select, poll, epoll。
select
select模型监听的三个事件:读数据事件,写数据事件,异常事件。
使用select模型的步骤如下:
- 我们确定要监听的监听fd列表
- 调用select监听所有监听fd,阻塞线程。
- select只有当有事件出现并且有事件的fd已经等待完毕
- 如果是创建一个连接事件:
- 创建一个连接套接字,连接fd
- 将连接fd和监听fd集合放在一起
- 如果是一个读写事件:
- 遍历所有fd,判断是否是准备好的fd
- 如果是准备好的fd,进行业务读写逻辑
- 循环进入select。
select一次可以监听1024个文件描述符。
poll模型
poll传递给内核的是:
- 监听的fd集合
- 需要监听的事件类型
- 实际发生的事件类型
poll的模型逻辑是:
- 我们确定要监听的监听fd列表
- 调用poll监听所有监听fd,阻塞线程。
- poll只有当有事件出现才解除阻塞
- 如果是创建一个连接事件:
- 创建一个连接套接字,连接fd
- 将连接fd和监听fd集合放在一起
- 如果是一个读写事件:
- 遍历所有fd,判断是否是有读写事件的fd
- 如果fd有读写事件,进行业务读写逻辑
- 循环进入poll。
poll比select优秀在它没有了1024的限制了。但是还是有一些缺陷,就是必须要遍历所有fd。
epoll
epoll的数据结构类似poll,但是在调用epoll的时候,它不是返回发生了事件的fd个数,而是返回了所有发生的事件,这个事件中可以查出发生事件的fd。
所以epoll的逻辑模型是:
- 我们确定要监听的监听fd列表
- 调用epoll监听所有监听fd,阻塞线程。
- epoll只有当有事件出现才解除阻塞,并且返回事件列表
- 遍历事件列表:
- 如果是创建一个连接事件:
- 创建一个连接套接字,连接fd
- 将连接fd和监听fd集合放在一起,继续epoll
- 如果是一个读写事件:
- 处理这个事件
- 循环进入epoll。
说白了,epoll就是我们逻辑上能想到的最优的通知机制。一群人去排队,有多个事件发生,警察来了,那么就告诉警察有哪几个列发生了什么事件,警察一个个处理就行了。
Reactor模型
有了IO多路复用的机制,我们就可以实现一种模型,叫做Reactor模型了。Reactor模型的理论基础起源于这篇论文:
https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf
里面最经典的一张图就是这个
reactor的五大角色:
- Handle(句柄或者是描述符)
- Synchronous Event Demultiplexer(同步事件分离器)
- Event Handler(事件处理器)
- Concrete Event Handler(具体事件处理器)
- Initiation Dispatcher(初始分发器)
简要来说,Reactor就是我们现在最正常理解的“事件驱动”,对,就是字面理解的那种。比如订阅一个kafka,我们会创建一个监听程序,监听kafka的某个topic,然后在监听程序中挂载几个处理不同消息的处理程序,每当有一个事件从topic进入的时候,我们就会有通过这个监听程序,通知我们的处理程序。处理程序来处理不同的消息。
这种所谓的通知机制,就叫做reactor。
这个kafka的例子,里面有一个监听事件的程序,它一定是一个同步的,一条消息来了,投递一个消息,就叫做 Synchronous Event Demultiplexer(同步事件分离器)。而这个消息,就是Handle(句柄或者是描述符)。我们需要将某个具体的事件处理函数,也就是上图的Concrete Event Handler(具体事件处理器) 挂载到监听的处理程序中。当然这里的每个Concrete Event Handler(具体事件处理器) 都必须遵照某种格式,比如定义了handle_event和get_handle接口。这种格式我们统称为Event Handler(事件处理器)。再回到监听事件,监听事件一定有一个挂载的具体map之类的结构,即哪个事件对应哪个处理程序,这个挂载的核心我们叫它Initiation Dispatcher(初始分发器)。
标准的处理流程描述如下:
-
当应用向Initiation Dispatcher注册Concrete Event Handler时,应用会标识出该事件处理器希望Initiation Dispatcher在某种类型的事件发生发生时向其通知,事件与handle关联
-
Initiation Dispatcher要求注册在其上面的Concrete Event Handler传递内部关联的handle,该handle会向操作系统标识
-
当所有的Concrete Event Handler都注册到 Initiation Dispatcher上后,应用会调用handle_events方法来启动Initiation Dispatcher的事件循环,这时Initiation Dispatcher会将每个Concrete Event Handler关联的handle合并,并使用Synchronous Event Demultiplexer来等待这些handle上事件的发生
-
当与某个事件源对应的handle变为ready时,Synchronous Event Demultiplexer便会通知 Initiation Dispatcher。比如tcp的socket变为ready for reading
-
Initiation Dispatcher会触发事件处理器的回调方法。当事件发生时, Initiation Dispatcher会将被一个“key”(表示一个激活的handle)定位和分发给特定的Event Handler的回调方法
-
Initiation Dispatcher调用特定的Concrete Event Handler的回调方法来响应其关联的handle上发生的事件
在这五种角色中,
其中的 Initiation Dispatcher(初始分发器) 是最重要的,我们也称其为Reactor。它本身定义了一些规范,同时提供了Handler的一些注册机制。
而Synchronous Event Demultiplexer(同步事件分离器) 在IO场景下,一般是由操作系统底层实现的,就是说操作系统底层必须能有这个能力,才能基于这个能力实现Reactor模型。在我们这个场景下,就是前面提到的linux的多路复用机制。
Handle(句柄或者是描述符)在IO场景下就是IO网络连接的fd。
而Event Handler(事件处理器) 和 Concrete Event Handler(具体事件处理器) 在IO场景下分为三种处理事件:连接事件,写事件,读事件。对于连接事件的处理器,我们称之为acceptor,读/写事件的处理器,我们统称为handler。
所以在IO场景下,Reactor 我们需要实现的三个关键角色为:reactor、acceptor、handler。
Redis的实现
在redis中,下面一张图就能说明其实现逻辑。
在redis中,有个reactor(叫做aeMain)接收客户端的redis请求。而在这个reactor中除了监听连接事件acceptor之外,还可以动态注册各种handler (aeCreateFileEvent)。当一个客户端请求进入的时候,调用 aeProcessEvents 来分发事件。
这个逻辑就很清晰了吧。整个就是redis的事件处理机制。
参考
https://cloud.tencent.com/developer/article/1420724
https://www.youtube.com/watch?v=PyiPA_liKKo
http://hxz.ink/2021/09/11/reactor-pattern/
https://time.geekbang.org/column/article/408491