Redis 6.0的多线程IO不参与内存淘汰，但能间接缓解淘汰延迟：通过将socket读写移至IO线程，释放主线程及时执行performEvictions()，避免因I/O阻塞导致淘汰滞后和OOM。
Redis 6.0 的多线程 IO 不直接参与内存淘汰，但它能间接缓解淘汰延迟——关键在于减少主线程被网络读写“堵住”的时间。
io-threads 怎么影响主线程执行淘汰的时机
内存淘汰（eviction）始终由主线程串行触发和执行，但它的启动前提是：主线程得有空去检查 maxmemory 是否超限、扫描候选 key、计算 LRU/LFU、调用 dbDelete。而主线程一旦被大量小请求的 socket 读写占满，就根本没机会跑淘汰逻辑。
- 未启用
io-threads时：所有 socketread()和write()都在主线程完成，高并发下主线程可能 80% 时间花在网络 I/O 上，导致淘汰检查滞后数秒甚至更久 - 启用
io-threads 4后：socket 读写移交给 4 个 IO 线程并行处理，主线程只做协议解析和命令执行，响应更及时，能更快进入performEvictions()流程 - 注意：这不是“淘汰变快了”，而是“淘汰更早被触发”，避免因主线程卡在 I/O 而堆积大量待淘汰 key，最终引发突发性 OOM 或拒绝写入
什么场景下这种缓解最明显
多线程 IO 对淘汰的帮助不是均匀生效的，它在特定负载模式下才真正起作用：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 大量短连接或高频小包请求（如每秒数万
GET/INCR）：IO 线程分担了连接建立、报文读取、响应打包等重复工作，主线程压力骤减 - 客户端使用 pipeline 但单次 payload 小（
- 网络带宽充足但 CPU 成为瓶颈：说明 I/O 处理本身在吃 CPU，此时开启
io-threads可释放主线程算力，让淘汰逻辑更稳定运行 - 反例：单个大请求（如
MGET 10000 keys）或大 key 写入（如LPUSH biglist ...）——这些仍由主线程解析和执行，IO 多线程对此无改善
为什么不能把淘汰也交给多线程做
有人会想：“既然 IO 能多线程，淘汰为啥不也并行？”答案是数据一致性风险不可控：
-
EXPIRE、SET、DEL和淘汰操作共享同一套redisDb.expires字典和dict主键空间，跨线程修改需加锁，反而比串行慢 - 淘汰必须与命令执行严格串行：比如一个
SET key value EX 60刚写入，另一个线程立刻把它当“LRU 最久”删掉，客户端收到成功响应却查不到数据 - LRU 时间戳更新、TTL 计算、平均存活时间（
avg_ttl）统计都依赖全局单调递增的server.unixtime，多线程并发读写易造成视图不一致 - 真正异步化的是“删除后的内存释放”（通过
lazyfree后台线程），不是淘汰决策本身——这是两个独立机制
容易被忽略的一点是：io-threads 开得越多，并不意味着淘汰越及时。超过 4~8 个后，线程调度和队列同步开销会上升，反而可能拖慢主线程获取任务的速度。实际压测中，多数业务用 io-threads 4 就已覆盖 90% 的 IO 瓶颈场景，盲目调高参数反而增加不稳定风险。
