lazyfree-lazy-eviction 控制内存淘汰时是否异步删除键，默认为 no，需显式开启以避免主线程卡顿；开启后内存释放延迟但可防阻塞，适用于多数微服务场景。
直接上结论：内存淘汰（eviction）触发大Key删除时，主线程卡顿是默认行为；必须显式开启 lazyfree-lazy-eviction 才能转为异步。不配置，DEL 或后台驱逐逻辑仍会同步释放内存，哪怕你用了 UNLINK 也无效——因为淘汰路径走的是另一套清理分支。
lazyfree-lazy-eviction 是什么，为什么它不默认开启
这个配置控制 Redis 在触发 maxmemory 淘汰策略（如 allkeys-lru、volatile-lfu 等）时，是否把被选中驱逐的 key 交给后台线程释放内存。
- 它默认是
no，不是疏忽，而是权衡：异步释放意味着内存不会立刻归还给操作系统，可能短暂超限 - 若业务对内存水位极其敏感（比如容器环境有硬性 RSS 限制），开启后可能出现
OOMKilled - 但绝大多数微服务场景下，延迟比几MB瞬时超限更致命——100ms+ 的淘汰卡顿足以触发上游熔断
怎么开，以及开了之后要注意什么
config set lazyfree-lazy-eviction yes 可立即生效，无需重启。但别只做这一步：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须确认你的 Redis 版本 ≥ 4.0（推荐 ≥ 6.2，修复了早期 lazyfree 的竞态问题）
- 开启后，用
INFO memory观察lazyfree_pending_objects是否持续非零——这是后台队列积压信号 - 如果该值长期 > 1000，说明后台线程跟不上淘汰节奏，需检查：
- 是否存在极多小 key 被高频淘汰（如短 TTL 的 session ID），导致任务提交开销反超收益
-
bio_close_file或bio_aof_fsync线程是否也被压满（INFO bio查看）
和 UNLINK、FLUSHDB ASYNC 的关系
它们互不替代，解决的是不同路径的阻塞：
-
UNLINK：仅对显式调用的单 key 删除生效 -
FLUSHDB ASYNC：只管清库动作，不管后续淘汰 -
lazyfree-lazy-eviction：专治maxmemory触发的被动驱逐
三者可以共存。例如你设了 maxmemory 2gb 且 lazyfree-lazy-eviction yes，当写入触发淘汰时，Redis 选出一个 50MB 的 Hash key 驱逐，就会调用 dbAsyncDelete() 而非 dbSyncDelete() —— 这和你在 CLI 里手动 UNLINK 同一个 key 的底层逻辑一致。
关键点容易被忽略：异步删除不等于内存立刻释放。后台线程只是把对象从字典摘除、加入释放队列，真正调用 zfree() 是后续步骤。这意味着 INFO memory | grep used_memory 的下降会有几十毫秒到几百毫秒延迟，监控告警不能只盯“瞬时内存使用率”，得结合 lazyfree_pending_objects 和 evicted_keys 综合判断。
