Redis 6.0多线程仅加速网络I/O（读请求、写响应），不提升GET/SET等命令执行速度；必须同时配置io-threads≥2且io-threads-do-reads yes才生效，推荐值为min(4, CPU核心数×0.7)。
Redis 6.0 的多线程 IO 不会加速 GET 或 SET 命令本身的执行，它只加速网络数据的读取和响应写出；配置不生效、性能不升反降，几乎全是参数漏配或超配导致的。
io-threads 和 io-threads-do-reads 必须同时启用
只设置 io-threads 4 没用——Redis 默认关闭读线程（io-threads-do-reads no），必须显式打开。否则主线程仍独自处理所有请求读取，I/O 线程只干写响应这一半活，pipeline 从第一步就卡住。
-
io-threads值必须 ≥ 2，设为 1 等价于禁用 - 修改后需执行
redis-cli config rewrite或重启 Redis，config set不支持热更新这两个参数 - 可通过
INFO threads查看io_threads_num和io_threads_active确认是否真正激活
线程数不是越多越好，4 核机器设 2～3 是安全值
超配会引发频繁上下文切换和锁竞争，top 里 %sy（系统态 CPU）飙升但 QPS 下降是典型信号。CPU 核心数是硬约束，不是内存或带宽。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐值 =
min(4, CPU核心数 × 0.7)，4 核设 2～3，8 核设 4～5 - 超过 8 个 I/O 线程在绝大多数场景下收益趋近于零，且每个线程独占缓冲区，增加内存占用
- 不要照搬“万兆网卡就得配 16 线程”这种错误经验——瓶颈不在带宽，而在单线程处理 socket 数据拷贝的效率
大 value 场景下收益最明显，小 key 高频场景提升有限
普通 GET token:abc123 这类小请求，单线程 memcpy 几十个字节开销可忽略；但批量 GET 一个 512KB 的 HTML 片段，或 MSET 数百 KB 序列化对象时，I/O 线程能分摊 memcpy 和协议解析耗时，显著减少延迟毛刺。
- 典型高收益场景：日志缓存（value > 100KB）、HTML 片段缓存、Protobuf/JSON 直存
- 若业务以 token 验证、计数器等高频小 key 为主，开启后吞吐提升可能仅 10%～15%
- 别忽略
jemalloc和lazyfree的协同影响：I/O 线程只管搬数据，大SET后内存分配、大DEL后内存回收仍在主线程，没调优这些，I/O 加速会被后续操作拖垮
真正容易被忽略的点是：多线程 IO 只解决网络搬运问题，命令执行、内存分配、键查找、哈希表操作全还在主线程。想靠它解决慢查询或大 key 阻塞，只会白忙一场。
