开启 lazyfree-lazy-user-del yes 后，del 命令自动变为异步删除，不再阻塞主线程；因 redis 单线程同步释放大 key 内存，导致请求排队、qps 归零甚至主从切换。

直接结论：开启 lazyfree-lazy-user-del yes 后，DEL 命令就自动变成异步删除，无需改代码，也不再阻塞主线程。

为什么 DEL 会卡住 Redis 主线程？

Redis 是单线程处理命令的，DEL 默认同步释放内存：它得把整个 Key（比如一个含 500 万字段的 HASH）逐个节点释放完，才返回 OK。期间所有新请求排队等待——实测删一个 100 万字段的 HASH 耗时 1.36s，QPS 归零。

这不是“慢”，是“不可接受的阻塞”。尤其在集群中，一次 DEL 可能触发主从切换。

常见错误现象：

• 执行 DEL bigkey 后，SLOWLOG 显示耗时 >1000ms
• 监控看到 Redis used_cpu_sys 突增，同时 connected_clients 积压
• 业务侧出现大量超时，但 INFO replication 显示主从延迟无异常——问题就在主线程被锁死

UNLINK 和 lazyfree-lazy-user-del 的区别在哪？

UNLINK 是 Redis 4.0 新增命令，语义和 DEL 完全一致，但底层调用的是异步删除路径：dbAsyncDelete。它立即返回 OK，把释放内存的工作交给 BIO 线程。

Redis Skill - 高性能缓存管理

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

下载

lazyfree-lazy-user-del 是 Redis 6.0+ 引入的配置开关，作用是让原有 DEL 命令“自动升级”为 UNLINK 行为：

• 设为 yes：所有 DEL 都走异步路径（只要满足后台删除阈值，见下条）
• 设为 no（默认）：DEL 仍同步执行，UNLINK 才异步
• 注意：DEL 是否真正异步，还取决于对象大小是否超过 LAZYFREE_THRESHOLD（默认 64）——小 Key 仍同步删，避免线程调度开销

如何安全开启并验证 lazyfree-lazy-user-del？

操作本身很简单，但有三个关键点容易被忽略：

• 只对 Redis 6.0 及以上版本生效；4.0/5.0 不识别该配置项，CONFIG SET 会报错 ERR Unsupported CONFIG parameter
• 临时生效用 CONFIG SET lazyfree-lazy-user-del yes，但重启后丢失；要持久化，必须写进 redis.conf 并重启或 CONFIG REWRITE
• 验证是否生效：先 CONFIG GET lazyfree-lazy-user-del 确认返回 "yes"，再用 SLOWLOG GET 1 对比删同一个大 Key 前后的耗时——应从秒级降到 0.x ms
• 别忘了检查 INFO memory 中的 lazyfree_pending_objects：它非零说明有异步任务在队列里，数值持续上涨可能意味着 BIO 线程积压（需查磁盘 I/O 或 BIO 线程数配置）

还有哪些 lazyfree 参数值得配？

单独开 lazyfree-lazy-user-del 只解决主动删 Key 的问题。生产环境建议一并评估以下参数：

• lazyfree-lazy-expire yes：让过期 Key 的清理也异步化（否则 TTL 到期那一刻可能卡住主线程）
• lazyfree-lazy-eviction yes：内存达 maxmemory 触发淘汰时，也走后台释放（避免 noeviction 失效后突发驱逐阻塞）
• lazyfree-lazy-server-del yes：影响 RENAME、RESTORE 等内部隐式删除场景（例如 RENAME a b 时若 b 已存在，会先删 b）
• 慎用 lazyfree-lazy-user-flush：开启后 FLUSHDB/FLUSHALL 也异步，但清空整个 DB 的对象量极大，BIO 队列易堆积，建议配合 client-output-buffer-limit 监控

这些参数默认都是 no，没有银弹，得根据你的数据规模、过期策略、淘汰压力来调——最常踩的坑，就是只开了 user-del，却忽略了 expire 和 eviction 这两个被动触发的“隐形炸弹”。