redis 6.0+ 通过 lazyfree 机制实现大 key 异步删除，主线程仅做逻辑摘除，后台线程释放内存；需满足版本 ≥6.0 且显式开启 lazyfree-lazy-eviction yes 才生效。

要让大 Key 删除不卡主线程，核心不是“怎么删”，而是“谁来删、什么时候删”。Redis 6.0+ 的 lazyfree 机制正是为此设计：把内存释放这个重活交给后台线程，主线程只做轻量级的逻辑摘除，响应时间稳定在亚毫秒级。

必须满足的两个前提条件

缺一不可，否则配置再全也无效：

• Redis 版本 ≥ 6.0（推荐 6.2 或更高）——4.0 虽引入 lazyfree，但淘汰场景（eviction）的异步支持直到 6.0 才正式加入
• 显式开启 lazyfree-lazy-eviction yes ——该配置控制的是「内存满触发的自动驱逐删除」，和 UNLINK、过期清理无关，必须单独打开

关键配置项及作用范围

不同删除场景由不同开关控制，不能混用：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• lazyfree-lazy-eviction yes：处理 maxmemory 达到上限后按策略（如 allkeys-lru）自动淘汰 Key 的内存释放
• lazyfree-lazy-expire yes：处理 过期 Key 被 Redis 主动清理时 的内存释放（建议开启）
• lazyfree-lazy-user-del yes：让客户端执行 UNLINK 命令时走异步路径（DEL 仍同步，UNLINK 才有效）
• slave-lazy-flush yes：从节点全量同步前 flush 本地数据时启用异步，降低同步延迟

注意：配置名必须完整准确，lazyfree-eviction yes 或 lazyfree_lazy_eviction yes 都会被 Redis 静默忽略。

配置生效与验证方法

改完 redis.conf 后，需重启或热重载：

• 重启实例最稳妥；若需热加载，先 CONFIG REWRITE 写入配置文件，再 CONFIG RELOAD
• 验证是否生效：INFO MEMORY 中观察 lazyfree_pending_objects ——淘汰发生时该值应短暂上升（后台线程排队中），随后归零
• 监控 redis-cli --stat，在 evicted_keys 快速增长期间，instantaneous_ops_per_sec 应保持平稳，无断崖下跌
• 极端情况下可抓栈：gstack $(pidof redis-server)，主线程调用栈中不应长时间停留在 freeObj 或 dictRelease

异步删除的注意事项

它解决阻塞问题，但不改变资源回收的本质：

• 内存不会立刻归还 OS，而是由 BIO 线程逐步释放，存在短暂内存占用滞后
• 阈值控制：只有 value 元素数 > 64（源码常量 LAZYFREE_THRESHOLD）才会真正移交后台；小 Key 仍同步删，避免线程调度开销
• UNLINK 替代 DEL 只影响主动删除，对淘汰场景完全无效——别指望靠换命令缓解内存压力