专栏首页PHPer 进击跟着大彬读源码 - Redis 4 - 服务器的事件驱动有什么含义?(上)

跟着大彬读源码 - Redis 4 - 服务器的事件驱动有什么含义?(上)

众所周知,Redis 服务器是一个事件驱动程序。那么事件驱动对于 Redis 而言有什么含义?源码中又是如何实现事件驱动的呢?今天,我们一起来认识下 Redis 服务器的事件驱动。

对于 Redis 而言,服务器需要处理以下两类事件:

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

接下来,我们先来认识下文件事件。

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

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

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

1 文件事件处理器的构成

图 1 展示了文件事件处理器的四个组成部分:

  • 套接字;
  • IO 多路复用程序;
  • 文件事件分派器(dispatcher);
  • 事件处理器;

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

而 IO 多了复用程序负责监听多个套接字,并向文件事件分派器分发那些产生事件的套接字。

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

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

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

2 IO 多路复用程序的实现

Redis 的 IO 多路复用程序的所有功能都是通过包装常见的 select、epoll、evport 和 kqueue 这些 IO 多路复用函数库来实现的。每个 IO 多路复用函数库在 Redis 源码中都对应一个单独的文件,比如 ae_select.c、ae_poll.c、ae_kqueue.c 等。

由于 Redis 为每个 IO 多路复用函数库都实现了相同的 API,所以 IO 多路复用程序的底层实现是可以互换的,如图 3 所示:

Redis 在 IO 多路复用程序的实现源码中用 #include 宏定义了相应的规则,**程序会在编译时自动选择系统中性能最高的 IO 多路复用函数库来作为 Redis 的 IO 多路复用程序的底层实现,这保证了 Redis 在各个平台的兼容性和高性能。对应源码如下:

/* 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 事件的类型

IO 多路复用程序可以监听多个套接字的 ae.h/AE_READABLEae.h/AE_WRITABLE 事件,这两类事件和套接字操作之间有以下对应关系:

  • 当服务器套接字变得可读时,套接字会产生 AE_READABLE 事件。此处的套接字可读,是指客户端对套接字执行 write、close 操作,或者有新的可应答(acceptable)套接字出现时(客户端对服务器的监听套接字执行 connect 操作),套接字会产生 AE_READABLE 事件。
  • 当服务器套接字变得可写时,套接字会产生 AE_WRITABLE 事件。

IO 多路复用程序允许服务器同时监听套接字的 AR_READABLE 事件和 AE_WRITABLE 事件。如果一个套接字同时产生了两个事件,那么文件分派器会优先处理 AE_READABLE 事件,然后再处理 AE_WRITABLE 事件。简单来说,如果一个套接字既可读又可写,那么服务器将先读套接字,后写套接字。

4 文件事件处理器

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

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

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

1)连接应答处理器

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

当 Redis 服务器进行初始化的时候,程序会将这个连接应答处理器和服务器监听套接字的 AE_READABLE 事件关联。对应源码如下

# server.c/initServer
...
/* Create an event handler for accepting new connections in TCP and Unix
 * domain sockets. */
for (j = 0; j < server.ipfd_count; j++) {
    if (aeCreateFileEvent(server.el, server.ipfd[j], AE_READABLE,
        acceptTcpHandler,NULL) == AE_ERR)
        {
            serverPanic(
                "Unrecoverable error creating server.ipfd file event.");
        }
}
...

当有客户端用 sys/scoket.h/connect 函数连接服务器监听套接字时,套接字就会产生 AE_READABLE 事件,引发连接应答处理器执行,并执行相应的套接字应答操作。如图 4 所示:

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

当一个客户端通过连接应答处理器成功连接到服务器之后,服务器会将客户端套接字的 AE_READABLE 事件和命令请求处理器关联起来(networking.c/acceptCommonHandler 函数)。

当客户端向服务器发送命令请求的时候,套接字就会产生 AR_READABLE 事件,引发命令请求处理器执行,并执行相应的套接字读入操作,如图 5 所示:

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

3)命令回复处理器 networking.c/sendReplToClient 函数是 Redis 的命令回复处理器,这个处理器负责将服务器执行命令后得到的命令回复通过套接字返回给客户端。

当服务器有命令回复需要发给客户端时,服务器会将客户端套接字的 AE_WRITABLE 事件和命令回复处理器关联(networking.c/handleClientsWithPendingWrites 函数)。

当客户端准备好接收服务器传回的命令回复时,就会产生 AE_WRITABLE 事件,引发命令回复处理器执行,并执行相应的套接字写入操作。如图 6 所示:

当命令回复发送完毕之后,服务器就会解除命令回复处理器与客户端套接字的 AE_WRITABLE 事件的关联。对应源码如下:

# networking.c/writeToClient
...
if (!clientHasPendingReplies(c)) {
    c->sentlen = 0;
    # buffer 缓冲区命令回复已发送,删除套接字和事件的关联
    if (handler_installed) aeDeleteFileEvent(server.el,c->fd,AE_WRITABLE);

    /* Close connection after entire reply has been sent. */
    if (c->flags & CLIENT_CLOSE_AFTER_REPLY) {
        freeClient(c);
        return C_ERR;
    }
}
...

5 客户端与服务器连接事件

之前我们通过 debug 的形式大致认识了客户端与服务器的连接过程。现在,我们站在文件事件的角度,再一次来追踪 Redis 客户端与服务器进行连接并发送命令的整个过程,看看在过程中会产生什么事件,这些事件又是如何被处理的。

先来看客户端与服务器建立连接的过程:

  1. 先启动我们的 Redis 服务器(127.0.0.1-8379)。成功启动后,服务器套接字(127.0.0.1-8379) AE_READABLE 事件正处于被监听状态,而该事件对应连接应答处理器。(server.c/initServer())。
  2. 使用 redis-cli 连接服务器。这是,服务器套接字(127.0.0.1-8379)将产生 AR_READABLE 事件,触发连接应答处理器执行(networking.c/acceptTcpHandler())。
  3. 对客户端的连接请求进行应答,创建客户端套接字,保存客户端状态信息,并将客户端套接字的 AE_READABLE 事件与命令请求处理器(networking.c/acceptCommonHandler())进行关联,使得服务器可以接收该客户端发来的命令请求。

此时,客户端已成功与服务器建立连接了。上述过程,我们仍然可以用 gdb 调试,查看函数的执行过程。具体调试过程如下:

gdb ./src/redis-server
(gdb) b acceptCommonHandler    # 给 acceptCommonHandler 函数设置断点
(gdb) r redis-conf --port 8379 # 启动服务器

另外开一个窗口,使用 redis-cli 连接服务器:redis-cli -p 8379

回到服务器窗口,我们会看到已进入 gdb 调试模式,输入:info stack,可以看到如图 6 所示的堆栈信息。

现在,我们再来认识命令的执行过程:

  1. 客户端向服务器发送一个命令请求,客户端套接字产生 AE_READABLE 事件,引发命令请求处理器(readQueryFromClient)执行,读取客户端的命令内容;
  2. 根据客户端发送命令内容,格式化客户端 argc、argv 等相关值属性值;
  3. 根据命令名称查找对应函数。server.c/processCommad()lookupCommand 函数调用;
  4. 执行与命令名关联的函数,获得返回结果,客户端套接字产生 。server.c/processCommad()call 函数调用。
  5. 返回命令回复,删除客户端套接字与 AE_WRITABLE 事件的关联。network.c/writeToClient() 函数。

图 7 展示了命令执行过程的堆栈信息。图 8 则展示了命令回复过程的堆栈信息。

总结

  1. Redis 服务器是一个事件驱动程序,服务器处理的事件分为时间事件文件事件两类。
  2. 文件事件是对套接字操作的抽象。**每次套接字变得可应答(acceptable)、可写(writable)或者可读(readable)时,相应的文件事件就会产生。
  3. 文件事件分为 AE_READABLE 事件(读事件)和 AE_WRITABLE 事件(写事件)两类。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 跟着大彬读源码 - Redis 2 - 服务器如何响应客户端请求?(上)

    上次我们通过问题“启动服务器,程序都干了什么?”,跟着源码,深入了解了 Redis 服务器的启动过程。

    北国风光
  • MySQL - 扩展性 3 负载均衡:眼花缭乱迷人眼

    基于这个思路,我们通常的做法是在服务器前端设置一个负载均衡器。负载均衡器的作用是将请求的连接路由到最空闲的可用服务器上。如图 1,显示了一个大型网站负载均衡设置...

    北国风光
  • 网络协议 17 - HTTPDNS:私人定制的 DNS 服务

        全球统一的 DNS 是很权威,但是我们都知道“适合自己的,才是最好的”。很多时候,标准统一化的 DNS 并不能满足我们定制的需求,这个时候就需要 HTT...

    北国风光
  • (新手小白)学生如何选择服务器配置[免认证]

    https://cloud.tencent.com/redirect.php?redirect=1039&cps_key=6f5f5aedea72d213ca3...

    勤劳的小蜜蜂
  • 你的业务针对腾讯优化了吗

    ) (1) 你也许了解 Public DNS服务的两个核心功能 一个是缓存 收到域名查询请求后 递归服务器会先看本地缓存是否有记录 另一个是递归查询 如果...

    腾讯云DNSPod团队
  • 如何选择腾讯云服务器配置?

    云服务器的配置选择,和网站或应用的类型、访问量、数据量大小、程序质量等因素有关,建议和您的网站或应用的开发技术人员沟通,选择最适合您的配置。

    用户5899800
  • 竹间智能简仁贤:基于情绪识别打造对话式AI,推进机器人融入商业 | 镁客请讲

    镁客网
  • XenApp 规划指南:虚拟化最佳实践

    桌面虚拟化包含有很多不同的虚拟桌面。其中一项是采用主机共享的模式,发布的桌面包含在Citrix XenApp服务器中。

    SuperDream
  • 简化开发、免运维,一图解读 TSF Serverless

    10月29日,腾讯全球数字生态大会成都城市峰会上,腾讯云重磅发布自研 PaaS 一站式开发平台 TSF Serverless(Serverless 微服务平台...

    腾讯云serverless团队
  • 构建NTP时间服务器

    程序员同行者

扫码关注云+社区

领取腾讯云代金券