Redis 6.0 之后的多线程：I/O 多路复用与命令执行

Redis 6.0 引入了一个重大特性：多线程 I/O。

等等，Redis 不是一直宣传「单线程快如闪电」吗？怎么又搞多线程了？

别急，这个多线程和你想的不太一样。

为什么需要多线程 I/O？

先来看一张图，理解 Redis 处理一个请求的完整流程：

┌──────────────────────────────────────────────────────────────┐
│                        客户端请求                              │
└──────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│  1. 接收连接                  │  主线程（单线程）             │
│  2. 读取数据                  │  3. 解析命令                  │
│  4. 执行命令                  │  5. 写回响应                  │
└──────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│                        客户端响应                              │
└──────────────────────────────────────────────────────────────┘

在 Redis 6.0 之前，步骤 1、2、3、5 都是串行执行的：

• 主线程等待 socket 可读
• 读取数据
• 解析命令
• 执行命令
• 等待 socket 可写
• 写回响应

问题出在哪里？

网络 I/O 是阻塞的。当客户端网络慢时，主线程会卡在 I/O 上白白等待。更糟糕的是，如果一次要写大量数据给客户端，主线程会一直等待写完成，期间无法处理其他请求。

多线程 I/O 的设计

Redis 6.0 的解决方案是：将耗时的 I/O 操作拆分到线程池执行。

┌─────────────────────────────────────────────────────────────────┐
│                         主线程                                    │
│   - 协议解析                                                     │
│   - 命令执行                                                     │
│   - 生成响应                                                     │
└─────────────────────────────────────────────────────────────────┘
              │                                    ▲
              │ 读取任务分发                      │ 结果收集
              ▼                                    │
┌─────────────────────────────────────────────────────────────────┐
│                      I/O 线程池                                  │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐                     │
│   │ I/O 线程1 │  │ I/O 线程2 │  │ I/O 线程3 │  ...              │
│   └──────────┘  └──────────┘  └──────────┘                     │
│         │                                   │                    │
│         ▼                                   ▼                    │
│   读取客户端数据                         写回响应数据             │
└─────────────────────────────────────────────────────────────────┘

核心变化：

1. 主线程不再阻塞在 I/O 上，而是通过线程池异步完成
2. 命令解析和执行仍在主线程，这是 Redis 高性能的关键
3. I/O 线程数量可配置，默认是 1（可通过 io-threads 配置）

配置与启用

Redis 6.0 提供了两个关键配置：

# I/O 线程数，设置为 4 表示 3 个 I/O 线程 + 1 个主线程
# 官方建议：4-6 之间效果最好
io-threads 4

# 是否启用多线程 I/O
# yes: 读写都使用多线程
# no: 仍然是单线程 I/O（但和 6.0 之前不同，解析逻辑已优化）
io-threads-do-reads yes

注意：I/O 线程数不包括主线程。所以设置为 4，实际有 4 个线程在处理 I/O。

工作流程详解

读取阶段

客户端1 ──┐
客户端2 ──┼──→ [主线程: 分发读取任务] ──→ [I/O 线程池: 读取数据]
客户端3 ──┘                              │
                                          ▼
                                 [主线程: 读取完成，开始解析]

1. 主线程调用 epoll_wait 得知某个 socket 可读
2. 主线程将读取任务放入队列
3. I/O 线程从队列取任务，读取数据到缓冲区
4. 主线程从缓冲区读取数据进行协议解析

写入阶段

[主线程: 生成响应]
         │
         ▼
[I/O 线程池: 写入数据到 socket]
         │
         ▼
    客户端收到响应

响应写入也是类似的机制：主线程生成响应数据，I/O 线程负责将数据写回客户端。

性能提升有多大？

根据 Redis 官方测试，在特定场景下：

场景	单线程 I/O	多线程 I/O (4 线程)
短命令 + 高并发	100%	110-120%
大量写操作	100%	150-200%
混合负载	100%	120-150%

为什么提升不是线性增加的？

因为命令执行（CPU 计算）仍然是瓶颈。当一个命令执行时间占比很高时，I/O 的优化空间就有限。

多线程 vs 单线程：如何选择？

// 判断是否需要启用多线程 I/O
public class RedisThreadingConfig {
    
    /**
     * 多线程 I/O 适合的场景：
     * - 大量客户端连接（数千以上）
     * - 响应数据较大（一次写大量数据）
     * - 网络延迟较高
     * - CPU 不是瓶颈（命令执行时间占比低）
     */
    public static boolean shouldUseMultiThreadIO() {
        // 如果 CPU 利用率已经很高，启用多线程 I/O 收益不大
        // 如果网络延迟高，I/O 线程可以并行处理更多请求
        return true;
    }
}

官方建议：

• 小规模部署（QPS < 10 万）：单线程 I/O 足够
• 大规模部署（QPS > 10 万）：考虑启用多线程 I/O
• 瓶颈在网络时：多线程 I/O 效果明显

你可能不知道的细节

1. 线程安全保证

I/O 线程只负责读写socket，不会访问 Redis 的数据。命令执行和数据修改都在主线程，所以不需要加锁。

// I/O 线程的工作（线程安全）
void ioThreadRead(int clientFd, byte[] buffer) {
    // 只是读取 socket 数据到缓冲区
    // 不涉及 Redis 内部数据
    read(clientFd, buffer, buffer.length);
}

// 主线程的工作（线程安全）
void processCommand(byte[] buffer) {
    // 解析命令
    // 访问 Redis 数据
    // 生成响应
}

2. 瓶颈转移

如果 I/O 是瓶颈，多线程 I/O 可以显著提升性能。但如果瓶颈在命令执行（CPU 密集型），多线程 I/O 反而可能降低性能（线程切换开销）。

3. 与多实例的区别

• 多线程 I/O：同一个进程内，多个线程分担 I/O 工作
• 多实例：多个 Redis 进程，各自使用独立的 CPU 核心

对于现代服务器（多核 CPU + 高速网络），多实例 + 多线程 I/O 是最优方案。

面试追问方向

问题	考察点
Redis 6.0 之前是纯单线程吗？	对后台线程和子进程的理解
为什么命令执行不用多线程？	数据结构线程安全、锁竞争问题
多线程 I/O 如何保证线程安全？	任务划分、无数据竞争
epoll 和 select/poll 的区别？	I/O 模型底层原理

总结

Redis 6.0 的多线程 I/O 是一个增量优化：

• 不改变：命令执行仍然是单线程，数据结构线程安全
• 改进的：网络 I/O 从同步阻塞变为异步并行
• 适用场景：高并发、大响应、多客户端连接

理解这个设计，你就能明白 Redis 的核心哲学：简单、专注，把一件事做到极致。

留给你的问题

既然多线程 I/O 提升有限，为什么 Redis 不把命令执行也改成多线程？

提示：考虑数据竞争、一致性、实现复杂度。