UNLINK 替代 DEL 是解决大键删除阻塞的第一步，它通过异步内存释放机制（由 lazyfree-lazy-user-del 控制）避免主线程阻塞，而 Redis 6.0+ 的多线程仅用于 I/O，不加速键删除。
UNLINK 替代 DEL 是解决大键删除阻塞的第一步
Redis 6.0+ 并没有用多线程去“处理客户端响应”来掩盖淘汰时延——这是常见误解。主线程仍负责命令解析、执行和响应组装；真正缓解阻塞的是 UNLINK 命令本身触发的异步内存释放机制，而非网络层的多线程掩盖。
当你对一个含百万成员的 SET 或几十 MB 的 STRING 执行 DEL，主线程会同步遍历、释放每个节点内存，期间完全无法处理新请求。而 UNLINK 立即返回 OK，并把实际内存回收交给后台线程（由 lazyfree-lazy-user-del yes 控制），主线程不卡顿。
-
UNLINK仅在 Redis 4.0+ 可用，6.0+ 默认启用 lazyfree 后台线程池 - 需确认配置项
lazyfree-lazy-user-del为yes（默认是 yes） - 对
EXPIRE过期键，可配lazyfree-lazy-expire yes实现异步过期清理 - 注意：
UNLINK不保证原子性：若执行中服务崩溃，可能残留部分已标记但未释放的内存
Redis 6.0+ 的多线程 I/O 只加速网络收发，不加速键删除
Redis 6.0 引入的多线程仅用于 socket 读写和协议解析（io-threads），命令执行、键空间操作、内存管理依然严格单线程。这意味着：
- 即使开启
io-threads 4，DEL big:key仍会阻塞主线程，且阻塞时间不变 -
UNLINK+ 后台 lazyfree 线程才是降低感知延迟的核心组合 - 多线程 I/O 的收益集中在高并发小包场景（如大量
GET/SET），对单个大键操作无加速效果 - 错误配置
io-threads反而可能因线程调度开销导致性能下降（尤其 QPS
如何验证大键是否真的被异步清理
不能只看 UNLINK 返回快，要确认后台线程是否在干活。关键检查点：
- 执行
INFO memory，观察lazyfree_pending_objects是否 > 0；该值下降说明后台正在释放 - 对比
MEMORY USAGE big:key和UNLINK后内存总量变化：若 RSS 没立刻降，说明 lazyfree 还在排队 - 查看慢日志：
SLOWLOG GET 1若出现unlink且耗时 > 1ms，说明 key 元数据极复杂（如嵌套 hash），连元数据解构都重 - 监控
evicted_keys和expired_keys：若它们突增但lazyfree_pending_objects持续高位，可能是后台线程不足（需调大lazyfree-lazy-user-del相关线程数）
真正容易被忽略的陷阱：大键 + AOF 重写同时发生
即使用了 UNLINK，若此时恰好触发 AOF 重写（bgrewriteaof），仍可能引发级联阻塞：
- AOF 重写本身会 fork 子进程，拷贝页表；若大键刚被
UNLINK标记但内存尚未释放，fork 开销剧增 - 子进程重写时需序列化当前键空间，若大键还没被 lazyfree 清掉，仍会被完整写入新 AOF
- 解决方案不是关 AOF，而是：禁用自动重写（
auto-aof-rewrite-percentage 0），改用人工触发 + 错峰执行 - 更彻底的做法：从源头避免大键——用分片（
product:stock:2023:001）、压缩（zstd序列化）、或改用流式结构（STREAM）替代巨型LIST
