Redis 6.0吞吐量提升源于多线程仅处理网络I/O，命令执行仍由主线程串行完成；io-threads需≥2且必须配合io-threads-do-reads yes才生效，否则配置无效。
Redis 6.0 的吞吐量提升不是靠“命令执行变多线程”，而是把网络 I/O 拆出去并行处理，主线程只管解析和执行命令——这个分工一旦调对，QPS 翻倍是常见结果，但配错反而拖慢。
io-threads 配置不生效的典型原因
很多用户改了 io-threads 却没看到性能变化，根本原因是：该参数默认为 0（即关闭多线程 I/O），且必须配合 io-threads-do-reads yes 才能启用读操作分流。
-
io-threads值必须 ≥ 2 才真正启用多线程；设为 1 等同于关闭 -
io-threads-do-reads默认是no，不打开它，IO 线程只负责写响应，不碰请求读取 - 配置后必须重启 Redis 实例，
CONFIG SET不支持热修改这两个参数 - Linux 下需确认内核版本 ≥ 2.6.22（epoll 支持），否则多线程 I/O 会自动降级
大 value 场景下 io-threads 数值怎么选
线程数不是越多越好。实测表明，当 value 普遍 > 100KB（如 HTML 片段、序列化对象直存），4～8 个 io-threads 是较优区间；超过 12 个后收益趋缓，还可能因线程调度反增延迟。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每个 IO 线程绑定一个 CPU 核心效果更稳，可用
taskset -c 1-7 redis-server redis.conf限定 CPU 亲和性 - 若业务混合大小 key（比如 token + 日志），建议先用
redis-benchmark -t set,get -n 100000 -c 500 -d 1024测 baseline，再逐步调高io-threads观察 QPS 和 P99 延迟拐点 - 注意：value 越大，IO 线程节省的 CPU 时间越多，但主线程解析 RESP 协议+查 dict 的耗时不变，别指望延迟也同比下降
为什么开了 io-threads 后 DEL 大 key 更卡了
IO 线程只管搬数据，不管内存回收。大 DEL 触发的内存释放仍由主线程同步完成，尤其在未启用 lazyfree-lazy-user-del yes 或未编译 jemalloc 时，主线程会长时间阻塞。
- 务必开启
lazyfree-lazy-user-del yes，让DEL变成异步释放 - 确认 Redis 编译时用了
jemalloc（运行redis-cli info memory | grep mem_allocator，输出应为jemalloc），否则lazyfree效果打折 - 避免在高峰期执行
FLUSHDB或KEYS *类全量扫描命令，这类操作完全绕过 IO 线程加速路径
真正决定吞吐上限的，从来不是 IO 线程数量本身，而是主线程能否及时消化掉 IO 线程送来的请求包——协议解析效率、dict 查找速度、内存分配器响应，任何一个环节卡住，多线程就变成“排队交作业”。
