Redis UNLINK 删除大 Key 为什么更稳：异步回收与内存峰值排查

线上清理缓存时，命令返回得很快不代表内存已经回收完。对包含大量成员的 List、Hash 或 Set，DEL 会把对象释放工作放在 Redis 主线程，短时间内可能拉高延迟；UNLINK 先把键从 Keyspace 中摘掉，再把释放工作交给后台线程，通常更适合在线删除大 Key。

需要降低删除动作对命令处理延迟的影响时，优先验证 UNLINK；但它只是把对象回收异步化，不会让内存立刻归还，也不能替代大 Key 治理。

Redis DEL 和 UNLINK 的差别不在“删没删掉”

在 Redis 中，键是否还存在由 Keyspace 决定。执行 UNLINK cart:items:2026-08 后，客户端下一次读取这个键会得到空结果；这一步和 DEL 的可见结果一致。区别从对象释放开始：DEL 继续在主线程拆解对象，UNLINK 只完成解除链接，再异步回收对象占用的内存。

官方命令说明把 UNLINK 的逐键解除链接工作标为 O(1)，实际回收则与对象内部的分配数量有关。这里的“更稳”是减少一次性回收对事件循环的阻塞，不是承诺删除命令没有任何资源成本。

先用小实验确认键的消失和回收队列

先准备一个有明确业务前缀的测试键，不要在生产环境直接对未知模式使用通配扫描：

redis-cli SET cache:unlink:probe ready
redis-cli EXISTS cache:unlink:probe
redis-cli UNLINK cache:unlink:probe
redis-cli EXISTS cache:unlink:probe
redis-cli INFO memory | grep lazyfree_pending_objects

正常情况下，第一次 EXISTS 返回 1，UNLINK 返回 1，第二次 EXISTS 返回 0。对于字符串这样的小对象，后台回收很快，lazyfree_pending_objects 可能还没来得及形成明显积压；这个实验主要验证命令语义和观测路径。

大 Key 删除时，真正要盯的是主线程延迟

把测试换成真实业务中的大对象后，观察重点应从“命令返回 1”转向三个相互关联的信号：删除前后的命令延迟、lazyfree_pending_objects 的变化，以及 used_memory 是否在后台回收后下降。

可以用 redis-cli --latency 做短时观测，再在删除前后记录：

redis-cli INFO memory | egrep 'used_memory:|lazyfree_pending_objects:'
redis-cli UNLINK session:region-a:large
redis-cli INFO memory | egrep 'used_memory:|lazyfree_pending_objects:'

UNLINK 成功后键已经不可读，但 used_memory 不一定同步下降；如果异步队列持续变大，说明回收速度跟不上删除速度，继续加大批量只会把压力推迟到后台线程。

批量清理不能只把 DEL 全部替换成 UNLINK

替换命令前先确认三个边界。第一，业务是否允许键立即不可读；第二，删除动作是否可能和写入并发发生；第三，后台回收队列能否承受这次清理。对于需要精确过期时间、分段迁移或可恢复操作的场景，直接删除仍然过于粗糙。

生产清理更适合采用小批次、可暂停的节奏，并为每一批保留键数量、开始结束时间和内存观察值。不要把 KEYS * 和一次性大范围删除放进在线请求路径；需要遍历时，应先评估 SCAN 返回的批量和业务时段。

常见问题：UNLINK 使用中的三个误区

UNLINK 返回 1，是不是代表内存已经释放？

不是。返回值代表成功从 Keyspace 中解除链接的键数量；对象的实际释放可能仍在后台线程排队。

小字符串也必须用 UNLINK 吗？

不必机械替换。小对象的同步释放成本通常有限，是否使用 UNLINK 应结合主线程延迟和清理批量判断。

lazyfree_pending_objects 一直增加怎么办？

先暂停继续删除，降低批量和频率，确认后台回收是否能追上；同时检查是否存在异常大的 Hash、List 或 Set。队列没有回落前，不要只看键已不存在就判定清理完成。

把删除结果验收到“键消失、队列回落、延迟可接受”

UNLINK 解决的是大对象释放不应长时间占住主线程的问题。上线前后的验收要同时覆盖 Keyspace 可见性、内存回收进度和命令延迟：键已经消失只是第一步，lazyfree_pending_objects 能回落、业务延迟没有异常抬升，才说明这次清理没有把风险转移到后台。