深入理解 Redis “快”的内幕：I/O 多路复用与多线程模型拆解

提到 Redis，大家的第一反应通常是“快”。但究竟为什么快？很多人会脱口而出：“因为它是纯内存操作”或“因为它用了 I/O 多路复用”。

然而，这只是表象。I/O 多路复用解决了“等待”的问题，但它并不负责“代工”。为了彻底理解 Redis 的性能精髓，我们需要深入到内核与主线程的交互细节中。

1. 核心链路：Redis 处理请求的三个阶段

我们可以把 Redis 处理一个请求的过程拆解为以下三个必经阶段：

第一阶段：监听（I/O 多路复用出场）

这个阶段解决了**“在门口傻等”**的阻塞问题。
Redis 线程调用 epoll_wait。它像个守门员，不需要盯着每一个观众（连接），只要有人往门里踢球（发数据），内核就会告诉它。

• 特性：非阻塞。Redis 可以同时监控成千上万个连接，而不需要为每个连接创建一个线程。

第二阶段：读写（数据搬运）

当 epoll 提示“某连接有数据了”，Redis 仍然需要完成具体的数据拷贝动作：将数据从内核的缓冲区拷贝到用户空间的内存中。

• 注意：这个“拷贝”动作本身其实也是一种 I/O 操作，且在 6.0 之前是同步完成的。

第三阶段：处理（解析与执行）

这是逻辑的核心，也是很多人的理解盲区。数据进入内存后，初始状态只是一串二进制字节流（RESP 协议格式，如 *3\r\n$3\r\nSET...）。

• 解析命令：Redis 必须按照协议，把这些字节解析成具体的命令。
• 执行命令：解析完成后，再去操作内存中的字典（Dictionary）等数据结构。

2. 性能分水岭：单线程 vs 多线程 (Redis 6.0)

Redis 的演进史，其实就是主线程如何从繁重的任务中“减负”的过程。

Redis 6.0 之前：纯单线程时期

• 协作方式：多路复用负责看门；主线程负责读入数据 -> 解析命令 -> 执行命令 -> 写回结果的所有工作。
• 痛点：如果解析一个超大的数据包（特别是耗时的 RESP 协议解析），主线程会被卡在“解析”或“读写”动作上，导致无法响应后续的其他请求。这就是所谓的“由于 I/O 读写导致的单线程瓶颈”。

Redis 6.0 之后：引入 I/O 多线程

• 协作方式：
  1. 多路复用：依然负责监听。
  2. I/O 线程（搬运工）：负责把数据读进来，并**在后台完成“解析”**工作。
  3. 主线程（大厨）：只负责最核心、最高效的**“执行命令”**。
• 结果：解析压力被分担，主线程变得更纯粹，系统的整体吞吐量得到了质的提升。

3. 小总结 📝

理解 Redis 的高性能，不能只停留在“多路复用”这个词上。关键在于意识到：

1. 多路复用 解决了“等待”的阻塞。
2. 解析和执行 才是消耗 CPU 资源的大头。
3. Redis 6.0 的进化，本质上是将“解析/读写”这些外围耗时任务外包给了多线程，而保留了单线程执行核心逻辑的简单性与原子性。