DEL会阻塞Redis 7.0主线程，因其同步释放大Key内存；UNLINK可显式替代，仅解引用并交由后台线程异步回收，避免阻塞。
Redis 7.0 中用 DEL 删除大 Key 会阻塞主线程，直接导致后续命令排队、客户端连接超时。这不是配置或网络问题，而是单线程模型下原子删除操作的必然结果——尤其当 Key 对应的内存释放耗时超过几百毫秒时，超时就几乎不可避免。
为什么 DEL 在 Redis 7.0 仍会卡住主线程
Redis 7.0 虽然默认启用了 lazyfree-lazy-user-del yes，但这个开关只对显式调用 UNLINK 生效。DEL 命令本身仍是同步删除：它要遍历、释放所有底层数据结构内存（比如一个含 50 万个成员的 Hash），期间主线程完全无法处理新请求。
- String 类型大 Key：value 超过 10KB 时，
DEL释放内存 + 清理元数据可能耗时 2–10ms；若 value 达 1MB，轻松突破 50ms - 集合类型大 Key：删除 10 万元素的
Set或ZSet，实际耗时与元素数量呈近似线性关系，常达百毫秒级 - Redis 7.0 的
active-defrag内存碎片整理若同时触发，会进一步放大延迟
UNLINK 是解法，但必须显式调用
Redis 7.0 把异步删除能力封装在 UNLINK 命令里，它把释放内存的操作移交后台线程，主线程只做“标记删除”和元数据清理，耗时稳定在微秒级。但注意：UNLINK 不是 DEL 的自动替代品。
- 客户端代码中必须把
DEL替换为UNLINK，否则旧逻辑照旧阻塞 - Lettuce/Jedis 等客户端库默认仍发
DEL，需检查封装层是否透传了UNLINK -
UNLINK返回值是1（成功）或0（key 不存在），语义与DEL一致，可安全替换 - 集群模式下，
UNLINK同样支持，但需确保所有节点版本 ≥ 6.0（7.0 已完全兼容）
真正容易被忽略的三个点
很多人以为开了 lazyfree-lazy-user-del 就万事大吉，结果线上还是超时——问题往往出在这三处：
- 监控日志里看到的是
DEL慢查询，不是UNLINK，说明业务代码或中间件没切过去 - 某些 ORM 或缓存框架（如 Spring Data Redis 早期版本）硬编码了
DEL，升级前需确认是否支持UNLINK配置项 -
UNLINK虽不阻塞主线程，但后台线程释放内存仍需资源；若同时有多个大 Key 被UNLINK，可能引发 I/O 或内存分配竞争，表现为used_memory_rss短暂飙升
别指望配置自动兜底。Redis 7.0 的异步删除是“显式契约”：你调 UNLINK，它才异步；你调 DEL，它就照旧卡死。线上还在用 DEL 删大 Key 的服务，超时只是时间问题。
