Redis 命令处理流程：从客户端请求到结果返回的全链路

好的，开始吧！

各位观众，晚上好！今天咱们来聊聊 Redis 的命令处理流程，保证让大家听完之后，下次面试再被问到这个问题，能直接把面试官侃晕，而不是自己晕倒。

咱们这次的目标是，从客户端一个简单的 GET mykey 命令开始，一直跟踪到 Redis 服务器处理完，然后把结果返回给客户端的全过程。别怕，咱们尽量用大白话，多敲代码，少说理论。

第一幕：客户端的呼唤 (Client Request)

首先，客户端（比如你的 Java 程序、Python 脚本、甚至只是 Redis CLI）想从 Redis 拿点东西，它会构建一个符合 Redis 协议（RESP）的命令。RESP 协议是一种文本协议，简单易懂。

例如，GET mykey 这个命令，会被编码成如下的 RESP 字符串：

*2rn$3rnGETrn$5rnmykeyrn

是不是觉得有点像古代的电报码？别慌，咱们来解读一下：

• *2rn: 表示这是一个包含两个元素的数组。
• $3rn: 表示接下来的字符串长度为 3。
• GETrn: 实际的命令字符串。
• $5rn: 表示接下来的字符串长度为 5。
• mykeyrn: 实际的键名字符串。

好吧，承认确实不那么直观。不过 Redis 就是这么玩的。客户端会通过 TCP 连接，把这个字符串发送给 Redis 服务器。

第二幕：服务器的守候 (Server Acceptance)

Redis 服务器一直监听着配置的端口（默认是 6379），等待客户端的连接。一旦有连接过来，Redis 会创建一个新的客户端结构体 redisClient 来代表这个连接。

这个 redisClient 结构体包含了客户端的所有信息，比如：

• 文件描述符 (fd): TCP 连接的文件描述符。
• 查询缓冲区 (querybuf): 用来存储客户端发送过来的命令。
• 参数 (argv): 命令参数，就是把 GET 和 mykey 拆开后存的地方。
• 参数数量 (argc): 参数的个数，GET mykey 就是 2。
• 回复链表 (reply): 存储要返回给客户端的数据。
• 等等…

可以简单理解为，Redis 服务器给每个客户端都准备了一个专属的“小本本”，记录着客户端的信息。

第三幕：命令的解析 (Command Parsing)

Redis 服务器接收到数据后，会把数据追加到 redisClient 的 querybuf 中。然后，Redis 会解析 querybuf 中的内容，按照 RESP 协议的规则，把命令和参数提取出来，存储到 redisClient 的 argv 数组中，并更新 argc 的值。

这个过程就像拆快递，把快递盒（querybuf）打开，然后把里面的东西（命令和参数）拿出来，分门别类地放好。

第四幕：命令的查找 (Command Lookup)

Redis 有一个命令表 redisCommandTable，里面存储了所有 Redis 命令的信息，包括命令的名字、执行函数、参数数量、标志等等。

Redis 会根据 redisClient 的 argv[0] (也就是命令的名字，比如 "GET")，在 redisCommandTable 中查找对应的命令。

如果找到了，Redis 就会把命令的指针存储到 redisClient 的 cmd 字段中。如果没找到，那说明客户端发了一个 Redis 不认识的命令，Redis 会返回一个错误信息，比如 "ERR unknown command ‘xxx’"。

第五幕：权限的检查 (Authentication Check)

如果 Redis 配置了密码（通过 requirepass 配置项），那么 Redis 会检查客户端是否已经通过认证。如果客户端没有通过认证，且尝试执行需要认证的命令（大部分命令都需要认证），Redis 会返回一个错误信息，比如 "ERR authentication required"。

第六幕：内存的预分配 (Memory Preallocation)

在执行命令之前，Redis 会预先分配一些内存，用来存储命令的执行结果。这样做可以提高性能，避免在命令执行过程中频繁地进行内存分配。

第七幕：命令的执行 (Command Execution)

终于到关键时刻了！Redis 会调用 redisClient 的 cmd 字段指向的命令执行函数，来执行客户端发送的命令。

以 GET mykey 为例，Redis 会调用 getCommand 函数来执行 GET 命令。getCommand 函数会根据 mykey 在 Redis 的数据库中查找对应的值。

• 如果找到了，getCommand 函数会把值存储到 redisClient 的 reply 链表中。
• 如果没有找到，getCommand 函数会把 NULL 存储到 redisClient 的 reply 链表中。

第八幕：AOF 和复制 (AOF and Replication)

在命令执行之后，Redis 会把命令写入 AOF (Append Only File) 文件中，以便在 Redis 重启时可以恢复数据。如果 Redis 配置了主从复制，那么 Redis 还会把命令发送给所有的从节点，让从节点也执行相同的命令，保持数据同步。

AOF 和复制都是为了保证 Redis 数据的可靠性和可用性。

第九幕：结果的返回 (Reply Generation)

Redis 会把 redisClient 的 reply 链表中的数据，按照 RESP 协议的规则，编码成字符串，然后通过 TCP 连接发送给客户端。

• 如果 GET mykey 找到了对应的值 "hello"，那么 Redis 会返回如下的 RESP 字符串：

  $5rnhellorn

• 如果 GET mykey 没有找到对应的值，那么 Redis 会返回如下的 RESP 字符串：

  $-1rn

  $-1rn 表示 NULL。

第十幕：善后处理 (Cleanup)

Redis 在把结果返回给客户端之后，会进行一些清理工作，比如清空 redisClient 的 querybuf，释放 argv 数组占用的内存，等等。

然后，Redis 会继续监听客户端的请求，等待下一个命令的到来。

总结：命令处理流程图

为了方便大家理解，我把整个命令处理流程用一个表格总结一下：

步骤	描述	涉及的数据结构	关键函数/操作
1. 客户端请求	客户端构建 RESP 协议的命令字符串，并通过 TCP 连接发送给 Redis 服务器。	无	send()
2. 服务器接收	Redis 服务器监听端口，接收客户端的 TCP 连接，并创建 redisClient 结构体来代表这个连接。	redisClient	accept(), createClient()
3. 命令解析	Redis 服务器把客户端发送的数据追加到 redisClient 的 querybuf 中，然后解析 querybuf 中的内容，提取命令和参数，存储到 redisClient 的 argv 数组中。	redisClient, querybuf, argv	processInputBuffer()
4. 命令查找	Redis 在 redisCommandTable 中查找 argv[0] 对应的命令，并把命令的指针存储到 redisClient 的 cmd 字段中。	redisClient, redisCommandTable	lookupCommand()
5. 权限检查	如果 Redis 配置了密码，那么 Redis 会检查客户端是否已经通过认证。	redisClient	authRequired()
6. 内存预分配	Redis 会预先分配一些内存，用来存储命令的执行结果。	无	beforeCommand() (伪代码，表示命令执行前的准备工作)
7. 命令执行	Redis 调用 redisClient 的 cmd 字段指向的命令执行函数，来执行客户端发送的命令。	redisClient	call(redisClient *c, int flags) (实际调用命令执行函数，例如 getCommand)
8. AOF & 复制	在命令执行之后，Redis 会把命令写入 AOF 文件中，并发送给所有的从节点。	无	feedAppendOnlyFile(), replicationFeedSlaves()
9. 结果返回	Redis 会把 redisClient 的 reply 链表中的数据，按照 RESP 协议的规则，编码成字符串，然后通过 TCP 连接发送给客户端。	redisClient, reply	addReply() (将结果添加到 reply 链表), writeToClient() (将 reply 链表中的数据发送给客户端)
10. 善后处理	Redis 在把结果返回给客户端之后，会进行一些清理工作，比如清空 redisClient 的 querybuf，释放 argv 数组占用的内存，等等。	redisClient	resetClient() (伪代码，表示清理客户端状态)

代码示例：模拟 RESP 协议的解析

为了让大家更直观地理解 RESP 协议的解析过程，我用 C 语言写一个简单的示例代码：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// 简单起见，假设命令和参数都小于 128 字节
#define MAX_LENGTH 128

int main() {
    char resp_string[] = "*2rn$3rnGETrn$5rnmykeyrn";
    char *command = NULL;
    char *key = NULL;

    char *token = strtok(resp_string, "rn"); // 使用 strtok 分割字符串
    int array_length = 0;
    int i = 0;

    while (token != NULL) {
        if (i == 0) {
            // 处理数组长度
            if (token[0] == '*') {
                array_length = atoi(token + 1); // 跳过 '*' 字符
                printf("Array Length: %dn", array_length);
            }
        } else if (i % 2 == 1) {
            // 处理字符串长度 (忽略)
            printf("String Length (ignored): %sn", token);
        } else {
            // 处理字符串内容
            if (command == NULL) {
                command = strdup(token); // 复制字符串，避免直接操作原始字符串
                printf("Command: %sn", command);
            } else if (key == NULL) {
                key = strdup(token);
                printf("Key: %sn", key);
            }
        }

        token = strtok(NULL, "rn"); // 获取下一个 token
        i++;
    }

    // 释放内存
    if (command != NULL) free(command);
    if (key != NULL) free(key);

    return 0;
}

这个代码只是一个简化的示例，没有处理所有的 RESP 协议的情况，但是它可以帮助大家理解 RESP 协议的基本结构和解析方法。

总结：Redis 的高性能之道

Redis 能够实现高性能，除了使用了高效的数据结构之外，还依赖于以下几个关键技术：

• 单线程模型： 避免了多线程之间的锁竞争，简化了代码逻辑。
• IO 多路复用： 可以使用 epoll、select 等技术，同时监听多个客户端的连接，提高了 IO 效率。
• 内存操作： 所有的数据都存储在内存中，避免了磁盘 IO 的开销。
• 事件驱动： Redis 使用事件驱动的方式来处理客户端的请求，提高了响应速度。

最后的忠告

理解 Redis 的命令处理流程，可以帮助我们更好地理解 Redis 的工作原理，从而更好地使用 Redis，解决实际问题。

记住，纸上得来终觉浅，绝知此事要躬行。多看源码，多敲代码，才能真正掌握 Redis 的精髓！

好啦，今天的分享就到这里，希望大家有所收获！如果大家还有什么问题，欢迎随时提问。感谢大家的聆听！