redis 7的i/o多线程仅加速网络读写，不防击穿；击穿需业务层用空值缓存、布隆过滤器或逻辑锁解决。开启需同时配置io-threads>1和io-threads-do-reads yes，线程数宜为物理核数一半（如8核设4），并避免主线程被慢命令阻塞。
Redis 7 的 I/O 多线程本身不防击穿，它只加速网络读写；击穿必须靠业务层缓存空值、布隆过滤器或逻辑锁解决。 但如果你的 Redis 实例在高并发下因网络吞吐瓶颈导致请求堆积、响应延迟飙升，进而放大击穿后果（比如大量回源压垮 DB），那 io-threads 就是关键杠杆——调不好反而更卡。
为什么开了 io-threads 还没效果？
常见现象是改了配置但 INFO threads 显示 io_threads_active:0，或者 QPS 上不去、延迟照抖。根本原因是：Redis 7.2 虽默认启用 I/O 多线程机制，但实际调度需两个开关同时打开。
-
io-threads必须设为大于 1 的整数（如io-threads 4），不能只写yes或留空 -
io-threads-do-reads yes必须显式开启，否则读请求仍走主线程，I/O 线程完全闲置 - 写请求（如
SET、INCR）不经过 I/O 线程，所以纯写密集场景看不到收益 - 若用的是 RESP2 协议，部分客户端解析逻辑可能绕过线程分发，建议升级到 RESP3
io-threads 数值设多少才合理？
不是越多越好，超配会引发上下文切换开销反噬性能。实测中，超过物理 CPU 核心数一半后，吞吐增长趋缓，延迟反而波动加大。
- 8 核机器推荐
io-threads 4，16 核推荐io-threads 6~8，别直接填16 - 如果 Redis 和业务进程混部，要预留至少 2 核给系统和其他服务，避免争抢
- 高连接数（>1w）+ 小包请求（如大量
GET key）场景，线程数可略高；反之，大包读写（如MGET万级 key）更依赖内存带宽，加线程意义不大 - 启动后务必执行
INFO threads，确认io_threads_active> 0 且io_thread_joined全为 1
和缓存击穿防护怎么配合？
I/O 多线程解决的是“请求进不来/回不出”的通道问题，而击穿是“请求进来后发现没数据，集体打穿 DB”的语义问题。两者必须分层应对：
- 在应用层，对查不到的 key 写入
SET key "" EX 60（空值 + 短 TTL），避免重复穿透；注意别用EXPIRE分两步，防止竞态 - 对热点 key 做二级本地缓存（如 Caffeine），拦截大部分重复查询，减轻 Redis 网络压力
- 用布隆过滤器预判 key 是否可能存在，无效请求在接入层就拒绝，不发往 Redis
- 如果用了
Redis Function（7.2+），可把空值判断+回源逻辑封装成原子函数，避免客户端重试时的并发窗口
真正容易被忽略的是：当 io-threads 开启后，主线程不再承担 socket 读，但命令排队、执行、响应组装仍在主线程。一旦某条慢命令（如 KEYS *、大 HGETALL）堵住主线程，所有 I/O 线程攒的请求都会排队等待——这时看监控会发现 io_threads_active 持续为 1，但 used_memory_rss 不涨、instantaneous_ops_per_sec 却断崖下跌。调优前，先确保没有阻塞型命令在线上运行。
