redis 7.0性能提升源于将网络读写（read/write）拆出主线程并行处理，命令执行仍由主线程串行保障原子性；需在redis.conf中显式配置io-threads≥4且io-threads-do-reads yes才生效，否则默认退化为单线程io。
Redis 7.0 的性能提升不是靠“换模型”，而是把原来单线程里最拖后腿的 read 和 write 拆出去并行干——命令执行（EXEC、GET、EVAL 等）仍由主线程串行处理，保证原子性；网络收发则交给可配数的 IO 线程池。这对缓存击穿类场景（如热点 key 突然大量并发访问）直接缓解了连接堆积、响应延迟飙升的问题。
redis.conf 中必须显式开启 IO 多线程
默认情况下 io-threads 是 1，等于没开。不改配置，哪怕你用的是 Redis 7.2，也还是单线程 IO。
-
io-threads 4：设置 IO 线程总数（含主线程），建议设为 CPU 核心数 - 1（例如 8 核机器设为 7） -
io-threads-do-reads yes：必须开启，否则只多线程写，不读——而击穿时最卡的是读请求涌入 - 注意：
io-threads值不能为 0 或 1，且必须在redis.conf中静态配置，运行时CONFIG SET不支持热修改
IO 多线程真正生效的两个硬条件
即使开了多线程，Redis 也会“懒启动”：只有满足条件才派活给 IO 线程，否则退化回主线程处理，避免小流量下线程调度反成负担。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 待写客户端数（
clients_pending_write） ≥io-threads × 2：这是触发多线程 write 的阈值 - 有至少一个 client 处于
postponeClientRead状态（即 read 请求已排队）且io-threads-do-reads为 yes：这是触发多线程 read 的前提 - 压测或线上突发流量前，建议用
CLIENT LIST观察pending_read和pending_write字段，确认是否真进多线程路径
击穿场景下，多线程 IO 能扛但不能治本
它解决的是“请求来了接不住”的问题，不是“key 没了查不到”的问题。击穿本质是缓存失效 + DB 查询洪峰，IO 多线程只是让 Redis 更快地把“MISS”响应发回去，不卡住连接层。
- 若下游 DB 已被打挂，Redis 再快也无济于事——必须配合布隆过滤器、逻辑空值、互斥锁等业务层方案
- 注意
client-output-buffer-limit配置：多线程 write 加速后，如果 client 消费慢（比如网络差或客户端卡顿），缓冲区更容易溢出，触发强制断连 - 高并发下
latency doctor可能显示command延迟低但fast-command延迟高——说明 IO 多线程已介入，瓶颈正从网络转向命令执行或内存分配
真正容易被忽略的是：IO 线程只负责 socket 层搬运，不碰数据结构、不执行 Lua、不参与事务校验。一旦你在 EVAL 脚本里做耗时计算，再多 IO 线程也救不了——那部分永远卡在主线程里。
