先来说说 UNLINK 为什么能有效缓解雪崩压力——其核心机制在于，它将最耗时的内存释放操作从主线程剥离，交由 BIO 后台线程处理。这样，主线程不会再因为单次删除而卡住整个实例。即使删除一个包含 2000 万个字段的 Hash，UNLINK 命令本身仍然能在毫秒级返回，真正的清理工作由后台异步完成。这其实不是“更快”了，而是“不堵车”的调度优化。
UNLINK 的核心思路非常直接：把内存释放从主线程移到 BIO 后台线程，避免单次删除阻塞整个 Redis 实例。 这不是性能上的飞跃，而是调度策略的优化——哪怕删除的是 2000 万字段的 Hash，UNLINK 也能在毫秒级别返回响应，后续清理工作全由后台线程承担。
UNLINK 和 DEL 的底层行为差异
DEL 采用同步释放方式：主线程必须从头到尾遍历整个数据结构，逐一释放每个元素的内存，最后才返回结果。一旦遇到大 Set 或 Hash，耗时直接飙升到秒级，期间所有其他请求都得排队等待。
UNLINK 则完全不同，它先进行“逻辑摘除”，再决定是否异步释放。具体流程大致是：先以 O(1) 复杂度从 db->dict 和 db->expires 中移除 key 的引用，然后调用 lazyfreeGetFreeEffort(val) 计算释放代价。代价计算规则非常直观：String 类型计为 1，Hash 根据其 HLEN，List 根据其 LLEN。如果计算出的代价超过 LAZYFREE_THRESHOLD（默认 64），才会被放入 BIO 队列进行异步处理；否则，仍然走同步删除的老路。
这意味着：删除一个只有 50 个字段的 Hash，UNLINK 和 DEL 的底层行为几乎完全一致，都是同步删除。但如果是删除一个 500 万字段的 Hash，UNLINK 会立即返回响应，真正的内存回收则交给后台线程扛住。
哪些场景必须用 UNLINK 而不是 DEL
以下场景如果使用 DEL，极易引发雪崩或主从切换：
- 删除已知的大
Key，例如粉丝Set、会话Hash、日志Sorted Set。 - 批量清理前，先用
SCAN扫描出疑似大 Key，再逐个UNLINK（禁用DEL）。 - 在 Lua 脚本里执行删除逻辑时，必须用
redis.call('UNLINK', key)，不能写DEL。 - 使用
RENAME覆盖目标 key 时，如果目标 key 本身是大 Key，需要确保lazyfree-lazy-server-del yes已开启，否则隐式DEL操作仍然会造成阻塞。
配置项 lazyfree-lazy-expire 为什么建议开
过期 key 的清理是被动触发的，业务层很难精确控制时机。试想一下，如果大量带 TTL 的大 Hash 在同一秒内过期，DEL 式的清理方式很可能瞬间把主线程压垮。
开启 lazyfree-lazy-expire yes 后，流程变为：过期检查仍然由主线程负责（这个操作很轻量），真正耗时的内存释放工作则转交 BIO 线程处理，与 UNLINK 共享同一套异步机制。如果配合 maxmemory-policy allkeys-lfu 使用，也需要同步打开 lazyfree-lazy-eviction yes。不过需要留意的是：这个配置可能导致内存释放存在一定滞后，务必通过压测确认 used_memory_peak 是否会超限。
另外补充一点：lazyfree-lazy-user-del 是 Redis 6.0+ 新增的配置项，设为 yes 后可以让普通的 DEL 自动降级为异步行为。但不推荐直接依赖它——语义上容易混淆，而且会掩盖业务中真实存在的大 Key 问题。
真正容易被忽略的一点是：UNLINK 并非万能药。它只解决了“删除动作不卡主线程”的问题，但 BIO 线程的负载会因此真实上升。如果连续 UNLINK 数百个上千万级的 Set，BIO 队列可能会积压，lazyfree_objects 持续上涨，这反而可能拖慢其他后台任务，比如 AOF rewrite 和 RDB save。一个实用的监控指标是 INFO memory | grep lazyfree 中的 lazyfree_pending_objects 值，一旦超过 1000，就该拉响预警了。
