redis 6.0的io-threads推荐值为min(4, cpu核心数×0.7)，四舍五入取整：4核设2或3，8核设4～5，16核以上仍建议≤6；必须≥2且配合io-threads-do-reads yes才生效，设为1等价于禁用。
io-threads设成多少才算不翻车
Redis 6.0的io-threads不是“越多越快”，超配反而拖垮QPS。关键约束是物理CPU核心数，不是逻辑核（比如启用了超线程的16逻辑核 ≠ 16可用核）。实测中，io-threads值超过8后，绝大多数场景收益趋近于零，且%sy（系统态CPU）会明显飙升。
推荐公式：min(4, CPU核心数 × 0.7)，四舍五入取整：
- 4核机器 → 设
2或3（不建议直接设4） - 8核机器 → 设
4～5（设6已接近临界） - 16核以上 → 仍建议≤
6，除非压测确认有持续收益
注意：该公式针对通用网络密集型场景；若Redis部署在NUMA架构上（numactl -H可查），必须配合server_cpulist绑定同node内核，否则跨node访存延迟会吃掉多线程增益。
为什么io-threads=1完全无效
io-threads 1在源码里被直接跳过线程创建逻辑，等价于禁用。Redis只在io-threads ≥ 2时才真正fork子线程。常见错误是配置了io-threads 4但没检查INFO threads返回的io_threads_num是否真等于4——如果还是0，说明配置根本没加载。
必须同时满足以下条件才可能生效：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
io-threads值≥2 -
io-threads-do-reads yes（默认为no，漏配=白配） - 执行
redis-cli config rewrite或重启实例（config set不支持热更新）
怎么确认线程真正在分担读压力
光看配置文件或CONFIG GET没用，得靠运行时指标验证：
- 执行
INFO threads，确认io_threads_num等于你设的值，且io_threads_active为1 - 压测时跑
top -H -p $(pgrep redis)，能看到多个io_thread_*线程的CPU占用明显上升（主线程%us应下降） - 对比开启前后
INFO stats中的instantaneous_ops_per_sec和rejected_connections：高并发下后者应显著减少
注意：每个socket固定由一个I/O线程处理，不存在“多个线程抢读同一个连接”的情况——这是避免竞态的硬性设计。
大连接数下线程数要更保守
当连接数超5000时，内存增长主因往往不是键值本身，而是每个连接的socket缓冲区、client结构体（含querybuf、reply等）、TLS上下文（如启用）等。此时盲目设高线程数会加剧内存压力：
- 每个I/O线程默认占2MB栈空间，8个线程就是16MB额外开销
- 每个线程独占输入/输出缓冲区，线程数×连接数决定总缓冲内存上限
- 建议满足「连接数 ÷ 线程数 ≥ 100」才有效果，例如6000连接，设
4比8更稳
真正容易被忽略的是「读写不对称」：写响应默认由I/O线程处理，但读请求必须靠io-threads-do-reads yes才能并行——漏掉这个开关，等于装了发动机却不点火。
