unlink能替代del降低延迟，因其主线程仅解引用（o(1)），内存释放交由bio线程异步完成；而del需同步遍历释放百万级元素，阻塞主线程致p99延迟飙升至数百毫秒甚至秒级。
Redis 6.0 的“异步淘汰”不是指过期键的自动删除，而是指 lazyfree 机制——它把内存释放操作从主线程剥离，避免大对象删除阻塞命令执行。 启用不当或理解偏差，反而会放大延迟抖动。
为什么 unlink 能替代 del 降低延迟
主线程执行 del key 时，若 key 对应的是大 hash / zset / list（比如百万级元素），Redis 会同步遍历并逐个释放内存节点，期间无法处理其他请求，P99 延迟可能飙升到数百毫秒甚至秒级。
unlink key 则不同：它立即从数据库字典中摘除 key，然后把实际的内存释放任务丢给后台线程（bio 线程）异步完成。主线程几乎不等待，延迟回归正常水平。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 适用场景：删除大 key、批量删除（
unlink支持多 key）、主从同步后清理临时结构 - 注意：
unlink不是“立刻释放内存”，只是解引用；真实释放由BIO_LAZY_FREE线程完成，可通过INFO bio查看队列积压情况 - 客户端调用无感知，但需确认 Redis 版本 ≥ 4.0（6.0 中默认更稳定）
lazyfree-lazy-eviction 和 lazyfree-lazy-expire 的真实作用
这两个配置控制的是 Redis 内部触发的自动释放行为，**不是手动调用命令**：
-
lazyfree-lazy-eviction yes：当启用内存淘汰（maxmemory）且需要驱逐 key 时，用异步方式释放被选中的 key（而非同步del） -
lazyfree-lazy-expire yes：对被动过期（访问时检查）的 key，也走异步释放；但注意——**主动过期（定时器扫描）仍同步释放**，这是设计限制 - 默认值均为
no，必须显式开启才生效；未开启时，哪怕用了unlink，淘汰/过期逻辑仍可能同步阻塞
容易被忽略的三个坑
异步释放不等于零成本，以下问题在高负载下极易暴露：
- 后台线程资源争抢：
BIO_LAZY_FREE线程数固定（默认 1），若大 key 删除密集，队列堆积会导致延迟转移到后续操作（如新 key 分配内存变慢），需配合bio_poll_step和 CPU 绑定优化 - 内存释放滞后：异步释放期间，
used_memory不下降，可能误触maxmemory淘汰，形成“伪 OOM”循环 - 主从复制干扰：从节点在重放
DEL命令时仍同步执行；若主节点用unlink，从节点收到的是DEL（协议不支持转发unlink），导致从节点延迟尖刺 —— 此时需统一用replica-ignore-disk-reads no+repl-backlog-size缓冲
真正起效的关键不在“开了几个线程”，而在于让所有可能触发大内存释放的路径（手动删、淘汰、过期）都进入异步轨道，并持续监控 INFO memory 中的 lazyfree_pending_objects 和 INFO bio 中的 lazy_free_pending。一旦这两项持续非零，说明异步通道已成瓶颈，该调参或拆分 key 了。
