Redis执行用户命令的过程，居然是这样的！

傷城~ 2023-10-14 15:49 124阅读 0赞

## 前言 ##

Redis想必每一个后端人员都是非常熟悉，在我日常的开发中，基本上使用Redis作为缓存中间件，而且使用Redis让我们完成很多需求、解决了不少业务问题，这里问个问题看看你会怎么答？

> Redis怎么执行命令的呢？

面对这个问题想必大部分朋友心里的答案是：客户端发送命令给到服务端，服务端收到执行之后再处理将命令执行结果返回给客户端，简单来说如下图：

![format_png][]

> 那么具体的更细节呢过程？

继续追问的话，能回答上来的还是比较少的，可能跟我之前一样无法表述出来，或者根本没深入了解学习过。

但是从今天开始我们讲能轻松应对，今天的文章将会深入Redis到底是如何执行我们输入的命令的，看了本文肯定能对你进阶学习Redis有很大的帮助！无论从面试角度，还是积累知识厚度方面都能有一个全面的认识。

分享文章内容前，老规矩，贴个文章大纲给大家，提前了解要讲的知识点。

![format_png 1][]

## 命令执行流程 ##

在Redis中有两个重要的角色，一个是客户端Client，一个是服务器Server。而且它们是一对多的关系，也就是说Server会保存每个与之相连接的Client的状态信息。

我们一起看看一条Redis操作命令从客户端发送到服务器如何接受、处理并返回的具体实现。

### 启动建立连接 ###

我们先看Redis服务端的启动，这也是客户端能建立连接的前提。

Redis服务器启动后，需要经过一些列的初始化及配置的设置，比如状态参数、用户配置、初始化数据结构等，主要包括下面这些。

![format_png 2][]

> Redis 客户端和服务器端是基于 socket 通信的，服务器端在初始化时会创建了一个 socket 监听，用于监听接客户端的 socket 连接

了解过源码的都知道，在 【redis.h/redisServer】 中redisServer结构体存储Redis服务器的所有信息，包括但不限于数据库、配置参数、命令表、监听端口与地址、客户端列表、若干统计信息、RDB与AOF持久化相关信息、主从复制相关信息、集群相关信息等。

而客户端连接服务器之前需要创建socket（一套固定的模式），然后根据设定的IP和端口号与服务器进行连接。

这里有个重要的知识点：在通过网络与redis服务器连接的普通客户端和lua脚本的客户端，服务器都会创建相对应的client 结构，用于记录他们的状态信息。

arduino复制代码//客户端在redisServer结构中的属性
    struct redisServer {
        ...
        // 存放普通客户端的列表
        list *clients;   /* List of active clients */
        // 存放lua脚本客户端
        client *lua_client;    /* The "fake client" to query Redis from Lua */
        ...
    };

> Redis客户端其实有三种类型：1：负责执行Lua脚本的伪客户端，2：用来加载aof文件的伪客户端，3：通过网络连接的普通客户端

到这里Redis客户端和服务端就完成连接，接下来继续看到底如何传输执行用户指令的！

### 客户端发送命令 ###

当用户在客户端输入一条执行命令时，客户端会将这个命令请求转换成Redis相关的通信协议格式，然后通过连接到服务器的套接字，将协议格式的命令请求发送给服务器。

> Redis 通讯协议（RESP 协议，REdis Serialization Protocol）

比如我们输入 set xkey xiaoxu 命令会转换成如下格式：

![format_png 3][]

看看转换后的格式注释，就知道各部分代表什么意思了

swift复制代码*3        //参数个数是*开头，3个参数
    $3        //参数长度是$开头，命令长度
    SET       //命令名称SET
    $4        //参数长度是$开头，key长度
    xkey      //key的内容
    $6        //参数长度是$开头，value长度
    xiaoxu      //value内容
    参数个数是*开头，参数长度是$开头，每个参数通过\r\n隔开
    回复协议格式：
    * 状态回复（status reply）的第一个字节是 “+”，如：+ok\r\n
    * 错误回复（error reply）的第一个字节是 “-“，如：-ERR unknown command xxx\r\n

### 服务端读取命令 ###

通过连接套接字让客户端的写入而变得可读，服务端将读取协议内容，并存储到客户端的缓冲区，这里的缓冲区是client结构的输入缓冲区。

![format_png 4][]

> 我们了解到每个连接到服务端的客户端，会保存在redisServer结构体中的clients链表中

arduino复制代码typedef struct client {
        ...
        // 客户端状态的输入缓冲区，保存客户端的命令请求
        sds querybuf;           /* Buffer we use to accumulate client queries. */
        // 下面这两个是解析出来的命令和参数
        int argc;               /* Num of arguments of current command. */
        robj **argv;            /* Arguments of current command. */
        // 一个是根据argv[0]解析出来的命令，一个是最后一次执行的命令
        struct redisCommand *cmd, *lastcmd;  /* Last command executed. */
        ...
    }

接着会对输入缓冲区中的命令请求进行分析，提取解析出命令请求中包含的命令参数，以及命令参数的个数，然后分别将参数和参数个数保存到客户端状态的argv属性和argc属性里面。

![format_png 5][]

关于插播个Socket小知识！这回事

> 每个 socket 被创建后，会分配两个缓冲区，输入 (发送)缓冲区和输出 (接收)缓冲区。在执行 send 之后，数据只是拷贝到了socket输入缓冲区，而什么时候向网络中输出，是由操作系统安排决定的。 一旦将数据写入到缓冲区，函数就可以成功返回，在识别到是 TCP协议后，再由 TCP 协议将数据从缓冲区一路发送到目标机器。 读取函数也是如此，它也是从输入缓冲区中读取数据，而不是直接从网络中读取。 注意：数据有可能刚被写入缓冲区就发送到网络，也可能在缓冲区中不断积压，多次写入的数据被一次性发送到网络，这取决于当时的网络情况、当前线程是否空闲等诸多因素，不由程序员控制

![format_png 6][]

### 服务端处理执行命令 ###

恭喜你，看到这里，你已经知道用户的操作命令令怎么传输和服务端怎么获取到指令了！继续往下看

查找命令

命令执行器根据客户端状态的argv\[0\]参数，在命令表中查找参数所指定的命令，本文中的argv\[0\]参数就是 set ，找到命令后保存到客户端状态的cmd属性。

> 命令表：其实就是一个字典，字典的键是命令名称，比如"set"、"get"、"del"；而值则是一个个redisCommand结构，每个redisCommand结构记录了一个Redis命令的实现信息。

![format_png 7][]

上图中:

SET命令的名字为"set"，实现函数为setCommand；命令的参数个数为-3，表示命令接受三个或以上数量的参数；命令的标识为"wm"，表示SET命令是一个写入命令。

GET命令的名字为 "get"，实现函数为getCommand函数；命令的参数个数为2，表示命令只接受两个参数；命令的标识为"r"，表示这是一个只读命令。

执行准备：参数、权限、内存校验

获得了执行需要的命令、参数后，服务器还需要做一些校验：

命令校验：检查客户端状态的cmd指针是否指向NULL。

参数校验：根据客户端cmd属性指向的redisCommand结构的arity属性，检查命令请求所给定的参数个数是否正确。

权限校验：检查客户端是否已经通过了身份验证，未通过身份验证的客户端只能执行AUTH命令。

内存检测：如果服务器打开了maxmemory功能，那么在执行命令之前，先检查服务器的内存占用情况，并在有需要时进行内存回收，从而使得接下来的命令可以顺利执行

其他校验..

调用命令实现函数

服务器将要执行命令的实现保存到了客户端状态的cmd属性里面，并将命令的参数和参数个数分别保存到了客户端状态的argv属性和argv属性里面，当服务器执行命令时，只需要一个指向客户端状态的指针作为参数，调用实际执行函数。

![format_png 8][]

被调用的命令实现函数会执行指定的操作，并产生相应的命令回复，这些回复会被保存在客户端状态的输出缓冲区里面（buf属性和reply属性），之后实现函数还会为客户端的套接字关联命令回复处理器，这个处理器负责将命令回复返回给客户端

后续：命令、参数、AOF

执行完毕后，会有一些后续操作，包括慢日志记录、redisCommand结构属性更新、AOF持久化记录、主从复制命令传播等。

### 回复消息给客户端 ###

命令实现函数会将命令回复保存到客户端的输出缓冲区里面，并为客户端的套接字关联命令回复处理器，当客户端套接字变为可写状态时，服务器就会执行命令回复处理器，将保存在客户端输出缓冲区中的命令回复发送给客户端。

发送完毕后，回复处理器会清空客户端状态的输出缓冲区，为下一个命令请求做好准备。

![format_png 9][]

当客户端接收到协议格式的命令回复之后，它会将这些回复转换成人类可读的格式，并打印给用户观看。

比如之前的 set xkey xiaoxu，服务器发送的 "+OK\\r\\n"，通过协议转换成 "OK\\n"

arduino复制代码redis > set xkey xiaoxu
    OK

ok，到这里其实整个发送命令和接收回复的流程就完成了，大家可以通过下图，加深下印象！

![format_png 10][]

## 事件和IO模型 ##

### 事件机制 ###

Redis服务器是一个事件驱动程序，它主要处理以下两种事件。

文件事件（file event）：利用I/O复用机制，监听Socket等文件描述符上发生的事件，这类事件主要由客户端（或其他Redis服务器）发送网络请求触发，根据不同执行的任务来为套接字关联不同的事件处理器。

时间事件（time event）：定时触发的事件，负责完成redis内部定时任务，如生成RDB文件、清除过期数据等

文件事件为不同的套接字关联了不同的处理器，组成部分分别是：套接字、I/O多路复用程序、文件事件分派器（dispatcher），文件事件处理器。

![format_png 11][]

我们主要看下文件事件，它跟文章内容息息相关。

Redis 客户端与 Redis 服务端建立连接，发送命令，Redis 服务器响应命令都是需要通过事件机制。

AE\_READABLE 事件：客户端与 Redis 服务器发起建立连接，监听套接字产生 AE\_READABLE 事件。

AE\_WRITEABLE 事件：响应客户端操作完成后，将产生 socket 的 AE\_WRITEABLE 事件，命令回复处理器完成处理后，将解除 AE\_WRITEABLE 事件与命令恢复处理器的关联。

### I/O多路复用 ###

I/O多路复用机制主要是为了减少线程切换带来的开销，同时也避免了 I/O 阻塞操作，从而大大提高了 Redis 的运行效率。

IO多路复用程序会同时监听多个socket，当被监听的socket准备好执行accept、read、write、close等操作时，与这些操作相对应的文件事件就会产生。

IO多路复用程序会把所有产生事件的socket压入一个队列中，然后有序地每次仅分配其中的一个socket发送给文件事件分派器，

文件事件分派器接收到socket之后会根据socket产生的事件类型调用对应的事件处理器进行处理。

![format_png 12][]

### 总结 ###

我们知道了一条Redis命令请求从发送到完成的步骤，答题如下：

1.  Redis客户端发送命令请求到服务器
2.  服务器读取命令请求，解析命令参数
3.  命令执行器根据命令参数查找命令的实际实现函数，然后执行，接着回复执行结果给客户端

服务器的Server结构使用Clients链表来链接多个客户端的状态，包括我们的输入请求和输出结果、解析的命令参数等。

同样我们也了解了Socket简单知识

好了，今天关于Redis命令的执行过程就分享到这！希望大家喜欢!

[format_png]: https://img-blog.csdnimg.cn/img_convert/4955ebd70a5ce97203a9219e2398e61e.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/408c95fcf675dbedabd5c1ee03ddf38d.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/2813f838ba16bcebea68755c0f10e086.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/9d0347f5849c2c746cf844040416a90b.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/23a268273c4e13e12f95616defe41881.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/f4c87c5dbb0de1fa388ac8fcd7501109.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/fbe499614a1eafe40031257e8357d136.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/fa35ff262864bf48bde0b424d9978e7b.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/c361ffe59ae3026552bfc8c6278dd913.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/22f98c5ca0ab21c670d7802dda858cfb.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/b5f2ef564354b4b450250057fc2b4d2c.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/81e84174354aa3eedd2f00a6960c2ffa.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/c6f15c8903af9efe514d1fd574a5e4f1.webp?x-oss-process=image/format,png