Redis 6.0 的 String 读写性能提升，并非单纯依靠配置 io-threads 就能自动实现——根本原因在于命令执行仍然由主线程串行处理。许多开发者误以为调大线程数即可直接加速 GET/SET，却发现 QPS 毫无变化。问题究竟出在哪里？关键在于：多线程仅负责网络 I/O 层面的数据搬运，而命令的实际计算依旧在单线程主线上串行执行。必须同时开启 io-threads-do-reads yes，并设置合理的线程数，才能真正解除网络读写环节的“瓶颈”。否则，配置形同虚设。
io-threads 参数本身并不能直接提升 String 读写性能——它仅控制网络 I/O 的线程数量，而 GET、SET 等命令的执行仍由主线程串行处理。真正生效的前提是同时启用 io-threads-do-reads yes，并且线程数设置合理；否则配置将无法发挥作用。
为什么仅设 io-threads 无效？
Redis 6.0 的 I/O 多线程必须实现“读+写”协同发挥作用：io-threads 定义线程池大小，但默认仅用于响应写操作（write），而请求读取（read）仍由主线程处理。若遗漏 io-threads-do-reads yes 配置，整个 pipeline 会卡在第一步——客户端请求根本不会被多线程分摊。
io-threads值必须 ≥ 2：设为 1 等同于停用多线程io-threads-do-reads默认值为no，必须显式修改为yes- 两个参数均需通过
redis.conf修改，CONFIG SET不支持热加载 - 修改后需执行
redis-cli config rewrite或重启 Redis 才能生效
io-threads 设置多少才算合理？
线程数并非越高越好，过度配置反而会引发频繁的上下文切换和锁竞争，导致 %sy（系统态 CPU）飙升，而 QPS 却下降。
- 推荐值 =
min(4, CPU核心数 × 0.7) - 4 核机器建议设为 2～3，8 核设为 4～5，超过 8 个线程带来的收益几乎为零
- 每个 I/O 线程会独占缓冲区，线程数越多内存占用也会随之增加
- 可通过
INFO threads命令查看io_threads_num和io_threads_active，确认是否真正激活多线程
String 场景下，开启多线程后为何依然慢？
因为 I/O 线程仅加速数据搬运（read/write 系统调用），并不加速命令执行本身。遇到以下情况，即使线程数再多也无济于事：
GET返回 value 超过 100 KB：主线程的 memcpy 耗时成为主导，I/O 加速无效maxmemory接近阈值：LRU/LFU 驱逐扫描会阻塞主线程，可观察evicted_keys是否突增来验证- 启用了
notify-keyspace-events（尤其是包含E或g选项）：每次 key 变更都广播事件，主线程负担翻倍 - 客户端未使用连接池：TCP 握手和认证开销会消耗掉所有 I/O 吞吐带来的增益
真正适合用 io-threads 提速的应用场景
只有当性能瓶颈确实位于网络 I/O 层时，配置多线程才有实际意义。典型的高收益组合包括：
- 客户端连接数 ≥ 500，且平均 QPS ≥ 20k（纯
GET/SET操作） - 网卡中断集中在单核上（通过
cat /proc/interrupts | grep eth0发现某核 IRQ 占比超过 70%） - 存在大量大 value 操作：如日志缓存、HTML 片段、序列化对象直接存储（value 超过 100 KB）
- 批量操作已改用
MSET/MGET，客户端启用了连接池，并设置了合理的 pipeline 深度（16–128）
实际优化效果取决于主线程是否被其他任务拖累——例如未调优 jemalloc 或未开启 lazyfree，导致大 DEL 后内存回收仍然阻塞主线程，此时 I/O 加速就形同虚设。配置只是性能优化的一半，不能脱离整体使用模式单独生效。
