Redis 删除大键用 DEL 还是 UNLINK

Redis 删除大键时，优先看的是删除动作会不会占住主线程，而不是命令名字里有没有“异步”二字。DEL 会在当前命令里完成对象释放；UNLINK 先把键从 keyspace 中摘掉，再把实际内存回收交给后台线程。小字符串或低峰维护可以继续用 DEL，在线高峰删除大 Hash、List、Set、Sorted Set 时通常更适合 UNLINK。

一句话判断：需要尽快让大键从业务视图消失、又不想把复合值释放成本压在请求线程上，用 UNLINK；需要同步完成释放，或者键很小、操作在维护窗口内，用 DEL。

大键删除时，先分清“摘除键”和“回收内存”

这两个命令的业务结果很接近：键存在就删除，不存在就跳过，并返回实际删除的数量。差异出现在删除一个复合值时。Redis 官方文档把 DEL 的复杂度描述为：删除键本身按键数量计算，List、Set、Sorted Set 或 Hash 还要按其中的元素数量承担释放成本；字符串值则是常量级。

UNLINK 的前半段只负责从键空间解除关联，因此每个键的命令侧复杂度是 O(1)，对象由多少内存分配组成，则由后台线程继续处理。也就是说，UNLINK 改善的是请求路径上的阻塞风险，不是让回收工作凭空消失。

# 小键或维护窗口内的同步删除
redis-cli DEL session:small

# 大集合在线删除：先摘除键，释放成本移到后台线程
redis-cli UNLINK cache:product:list

# 多键操作前先确认集群键槽约束，不要把跨槽批量删除当成单机语义
redis-cli CLUSTER KEYSLOT cache:product:list

按业务负载选择：大键和高峰期优先考虑 UNLINK

如果值只是短字符串，释放成本很小，DEL 更直接；如果是拥有大量元素的 Hash 或 List，且删除发生在用户请求持续进入的实例上，DEL 可能把释放工作放在事件循环里，放大尾延迟。此时可以用 UNLINK，让业务立刻看不到这个键，同时给后台回收留出空间。

但不要把 UNLINK 当成“永远更快”。删除速度过快时，后台回收也可能形成积压；如果进程仍然持续写入，分配器还可能复用已释放的内存，而不是马上把 RSS 归还给操作系统。对需要严格控制资源释放时点的维护脚本，先确认是否真的要求同步完成，再决定命令。

• 小值、低频删除：使用 DEL，语义简单，执行路径短。
• 大值、在线高峰：优先 UNLINK，并限制批量规模，避免后台回收队列被瞬间压满。
• 集群多键删除：先检查 key slot 和客户端的批量策略，命令选择不能绕过跨槽限制。

生产环境要同时观察延迟、键空间和进程内存

判断 UNLINK 是否适合，不能只看命令返回了整数。返回 1 只说明键已经从 keyspace 摘除；后台释放何时结束、分配器是否把页归还给操作系统，属于另外两层状态。Redis 官方内存文档也提醒，删除键后 RSS 不一定同步下降，空闲块可能先被分配器复用。

可以在灰度期间打开延迟监控，并配合内存快照观察趋势：

# 只在需要定位延迟时设置阈值，数值按业务的毫秒预算调整
redis-cli CONFIG SET latency-monitor-threshold 100

# 查看最近记录的延迟事件
redis-cli LATENCY LATEST

# 对比 Redis 逻辑内存与进程驻留内存
redis-cli INFO memory

上线前的删除清单

先记录键的类型和元素数量，再把删除动作放进低风险窗口或小批量灰度；删除后分别观察 keyspace 是否已经没有目标键、延迟事件是否增加、逻辑内存和 RSS 是否按预期变化。若业务需要删除后立刻确认资源已经释放，不要只因为返回值成功就把 UNLINK 当作同步完成。

最后保留回退方式：在低峰、可控键集合上使用 DEL 做对照，确认延迟预算能够承受后再决定是否长期采用。对于跨槽批量操作，还要让客户端按 slot 拆分请求，不要用一个看似方便的命令掩盖集群约束。

相关问题

UNLINK 会不会让键还能被 GET 读到？

不会。键从 keyspace 摘除后，后续读取看不到它；延迟的是底层对象内存回收，不是业务可见性。

DEL 一定比 UNLINK 慢吗？

不一定。对小字符串，二者差别通常不值得放大；真正需要警惕的是复合值元素很多时，DEL 的同步释放会占用当前命令路径。

为什么删除后 Redis RSS 还很高？

后台回收完成也不等于操作系统立即收回页面，分配器可能保留并复用空闲块，所以要结合逻辑内存、RSS 和后续写入趋势判断。