*Redis UNLINK 命令
异步删除一个或多个 key。与 DEL 不同，UNLINK 将删除操作放入后台线程，不阻塞主线程。
*语法
UNLINK key [key ...]
*参数说明
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| key | String | 是 | 要删除的键名，可一次删除多个 |
*返回值
| 条件 | 返回值 |
|---|---|
| 成功 | 删除的 key 数量（Integer） |
*时间复杂度
O(1) 每个 key（主线程），实际内存释放由后台线程处理。
⚠️ 注意：UNLINK 立即返回，但大 key 的内存实际释放可能需要时间。极端情况下后台线程可能跟不上释放速度。
*示例
> SET k1 v1
> SET k2 v2
> UNLINK k1
(integer) 1
> UNLINK k1
(integer) 0
# 批量删除
> UNLINK k2 k3 k4
(integer) 1
*常见错误
- 误认为立即释放内存：UNLINK 主线程立即返回，但大 key 内存由后台线程释放，有短暂延迟。
*最佳实践
- 生产环境删除大 key：永远用 UNLINK 替代 DEL，避免阻塞 Redis。
- 批量删除大量 key：UNLINK + SCAN 分批清理，比 FLUSHDB/FLUSHALL 更安全可控。
- 监控后台线程：INFO 查看
lazyfree_pending_objects，监控待释放对象数量。
*FAQ
Q: UNLINK 和 DEL 有什么区别？ A: DEL 同步删除，立即释放内存但可能阻塞主线程；UNLINK 异步删除，主线程立即返回，后台线程释放内存。
Q: UNLINK 一定不阻塞吗？ A: 绝大多数情况下不阻塞。但 key 本身很小（<64KB 或 ziplist）时，UNLINK 可能直接同步删除，因为异步 overhead 不值得。
Q: 后台线程来不及释放怎么办？
A: 极少见。大量大 key 被 UNLINK 时，后台线程可能暂时积压。监控 lazyfree_pending_objects，必要时降低删除频率。