redis 6.0多线程仅加速网络i/o（读请求、写响应），不提升命令执行速度；必须同时配置io-threads≥2且io-threads-do-reads yes才生效，推荐线程数=min(4, cpu核心数×0.7)。
Redis 6.0 的多线程模型本身不提升单条命令执行速度，它只加速网络 I/O 环节——读请求数据、写响应数据。QPS 提升来自主线程被“释放”出来专注命令执行，不再卡在 memcpy 和系统调用上。
io-threads 配置不生效的常见原因
很多用户改了 io-threads 4 就以为启用了多线程，结果 INFO threads 显示 io_threads_num:0，QPS 毫无变化。核心问题就两个：
-
io-threads-do-reads默认是no，必须显式设为yes，否则 I/O 线程根本不参与读取，整个 pipeline 堵在第一步 -
io-threads设为1等价于禁用（源码里会跳过线程创建逻辑），最小有效值是2 - 这两个参数不支持
CONFIG SET热更新，必须用CONFIG REWRITE写入配置文件，或直接重启 Redis
io-threads 数值怎么选才不翻车
不是越多越好，超配反而拉垮性能。关键约束是 CPU 核心数和实际负载特征：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐值 =
min(4, CPU核心数 × 0.7)：4 核机器设2或3，8 核设4～5 - 设成
8或16在普通服务器上大概率触发频繁上下文切换，top里%sy（系统态 CPU）飙升，但 QPS 不升反降 - 超过 8 个 I/O 线程在绝大多数场景下收益趋近于零，还会增加内存占用（每个线程独占输入/输出缓冲区）
- 如果业务以小 key 小 value 为主（如
GET uid:123），I/O 线程收益有限；大 value 场景（如批量GET1MB 字符串）收益最明显
如何确认多线程真正在干活
光看配置文件没用，得靠运行时指标验证是否真正激活：
- 执行
INFO threads，检查io_threads_num是否等于你设的值，io_threads_active是否为1 - 用
redis-cli --stat观察 QPS 变化，同时开另一个终端跑top -H -p $(pgrep redis)，能看到除主线程外多个io_thread_*线程的 CPU 占用明显上升 - 对比开启前后
INFO stats中的instantaneous_ops_per_sec和rejected_connections：高并发下后者应显著减少 - 注意：同一时间一个 socket 只由一个 I/O 线程处理，这是避免竞态的设计底线，别指望“某个连接被多个线程抢着读”
真正容易被忽略的是「读写不对称」：写响应默认由 I/O 线程处理（无需开关），但读请求必须靠 io-threads-do-reads yes 才能并行——漏掉这个，等于只装了发动机却不点火。
