lazyfree-lazy-eviction仅在maxmemory触发LRU/LFU主动淘汰且淘汰对象为大集合或超长string时生效；对DEL、FLUSHDB、EXPIRE清理等仍同步阻塞，需结合日志、INFO memory监控及合理BIO线程配置方可有效。
开启 lazyfree-lazy-eviction 确实能缓解大Key淘汰时的阻塞，但不能单独依赖它来解决卡顿——它只对“内存淘汰触发的删除”生效，而像 DEL、FLUSHDB、EXPIRE 后续的被动清理等仍会同步阻塞。
哪些淘汰场景会被 lazyfree-lazy-eviction 覆盖？
仅当 Redis 因 maxmemory 触发 LRU/LFU 等策略主动驱逐 Key 时，且该 Key 是集合类（hash、list、set、zset）或 string（超长值）时，才会走异步删除路径。
- 不生效的情况包括：
DEL key命令、RENAME覆盖、FLUSHALL/FLUSHDB、过期 key 在惰性删除或定期删除中被真正清理时 - 即使开启，若淘汰的是单个
string小值（如 1KB），Redis 仍可能直接同步删——因为异步开销反而更高 - 该配置不影响
evict阶段的查找和决策耗时，只影响“删除数据结构”这一步是否异步
如何确认它是否在起作用？
靠日志和监控比靠配置更可靠。Redis 6.0+ 会在 redis.log 中记录异步删除任务的提交和完成：
# 出现这类日志说明 lazyfree 已介入 12345:M 12 Jan 10:23:45.678 * Asynchronous freeing of dict entry for key 'big:hash:2024' 12345:M 12 Jan 10:23:45.682 * Async delete completed for key 'big:hash:2024'
- 用
INFO memory查看lazyfree_pending_objects是否持续非零：> 0 表示有积压任务，可能是后台线程跟不上或大Key过于密集 -
CONFIG GET lazyfree-lazy-eviction返回"yes"仅表示开关打开，不等于正在异步删——得看日志和指标
必须配合做的三件事，否则效果打折甚至出问题
异步删除不是银弹，它把压力从主线程转移到了 BIO 线程，若没管好上下游，可能引发新瓶颈：
- 确保
bio-thread-num（Redis 7.0+）或旧版的io-threads配置合理：默认 1 个 BIO 线程，遇到大量大Key淘汰时容易积压；可设为 2～4（需压测验证） - 禁用
activedefrag与lazyfree同时运行：内存碎片整理本身也耗 CPU，叠加异步删除可能加剧延迟抖动 - 业务层仍要避免写入单 Key > 1MB 的集合：即使异步删，序列化、内存释放、页回收仍占资源；优先拆分为
key:001、key:002等小 Key
真正难处理的从来不是“怎么开异步”，而是“为什么会有上百万成员的 zset 存在”。lazyfree-lazy-eviction 是兜底手段，不是设计替代品。
