不存在。redis 6.0的内存淘汰始终由主线程串行执行，多线程仅用于网络io，不参与驱逐、过期检查或命令执行，以保障数据一致性与原子性。
Redis 6.0多线程淘汰是否真实存在？
不存在。Redis 6.0引入的是多I/O线程，仅用于网络请求读取与响应写入；键的淘汰（eviction）仍由主线程串行执行，和淘汰策略（如allkeys-lru）无关。所谓“多线程淘汰”是常见误解，混淆了I/O线程与淘汰逻辑的职责边界。
主线程在每次写入前必须完成内存检查+候选键采样+淘汰决策+实际删除，这一整套流程无法并行——因为淘汰涉及全局LRU/LFU状态更新、哈希表重哈希、内存释放等强一致性操作，加锁或拆分都会破坏原子性与性能收益。
-
UNLINK是唯一能异步化的“删除动作”，但它只作用于已选定的淘汰键，不改变淘汰决策本身 - 淘汰策略的采样过程（如
maxmemory-samples 5）始终在主线程内完成，样本数越高，单次淘汰延迟越明显 - 即使开启
io-threads 4，当maxmemory触达后，写入吞吐量瓶颈仍在主线程的淘汰循环，而非网络层
真正影响淘汰阶段吞吐量的关键配置
吞吐量下降主因不是“淘汰慢”，而是主线程被卡在“找谁删”和“删完再写”的同步等待上。优化重点应落在减少单次淘汰开销、降低触发频率、避免阻塞式删除：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 把
maxmemory-policy从volatile-lru换成allkeys-lfu：LFU在热点数据稳定时淘汰更精准，减少无效采样轮次；但注意lfu-log-factor和lfu-decay-time需调优，否则冷数据可能长期滞留 - 调高
maxmemory-samples（默认5）到10～20：增加采样数可提升LRU/LFU命中率，降低反复淘汰同一类键的概率；但过高会加重主线程CPU负担，需压测验证 - 禁用
DEL命令清理大key，改用UNLINK：对即将被淘汰的哈希/集合等大结构，UNLINK将释放内存操作移交后台线程，避免主线程卡顿超100ms - 确保
activedefrag yes开启：内存碎片率>1.05时自动整理，防止因碎片导致看似有空闲内存却无法分配新对象
为什么升级到6.0后淘汰反而更卡？
部分用户升级后观察到eviction耗时上升，根本原因不是6.0变慢，而是它更严格地暴露了旧配置缺陷：
- 6.0默认启用
lazyfree-lazy-eviction yes，但该配置仅对UNLINK生效；若业务仍大量使用DEL删大key，淘汰时主线程仍需同步遍历释放，此时eviction延迟飙升 - 6.0的I/O线程会加速请求涌入，若
maxmemory设置过紧（如仅比峰值内存高10%），会导致淘汰更频繁，放大主线程压力 -
CONFIG SET maxmemory动态调整后，Redis不会立即触发淘汰，而是等下次写入才检查——若此时并发写入突增，多个客户端会同时卡在同一个淘汰循环里，表现为P99延迟尖刺
生产环境淘汰吞吐量兜底建议
不要依赖“淘汰更快”，而要让淘汰尽量少发生、发生时尽量轻量：
- 内存预留至少20%：按业务QPS峰值预估写入量，设置
maxmemory为预估内存占用的1.2倍，而非物理内存的75% - 所有缓存必须设
EXPIRE：避免noeviction或allkeys-*策略下永久键挤占空间；用ttl命令定期抽检无过期时间的key - 用
MEMORY USAGE和SCAN定位大key，配合MEMORY PURGE手动清理已过期但未被惰性删除的键空间 - 监控
evicted_keys和expired_keys指标差值：若前者远大于后者，说明淘汰策略正在大量驱逐有效数据，需立刻调整maxmemory-policy或扩容
淘汰不是性能优化点，而是容量治理失败的信号。真正的吞吐量保障，始于对数据生命周期的控制，而不是寄望于某次Redis版本升级能自动解决内存问题。
