Redis lazyfree 怎样降低删除大键的阻塞

Redis 删除大键时，真正让主线程卡住的通常不是“键名从字典里消失”，而是对象内部大量元素的内存释放。处理缓存批量淘汰、用户数据清理或历史列表裁剪时，可以优先用 UNLINK：它先把键从 keyspace 摘掉，再把较重的回收工作交给后台线程。这样能缩短命令响应路径，但不会让内存立刻下降，也不能消除后台回收带来的 CPU 压力。

官方地址：https://redis.io/docs/latest/

先把删除动作拆成摘链与回收

大字符串通常不容易把删除拖得很久，真正需要警惕的是包含大量分配单元的 Hash、List、Set 或 ZSet。DEL 会在主线程里完成删除和释放；UNLINK 对每个键的摘链动作是 O(1)，之后由其他线程处理对象回收。这里的“异步”只改变释放发生的线程和时间，不改变数据已经不可读这一事实。

我在处理大键时会先把目标分成两类：必须立刻从业务视图消失的键可以用 UNLINK；需要等待后台真正释放完成才能继续的内存预算，则必须额外观察回收进度。不要把 UNLINK 当成“删除零成本”，它只是把工作从请求关键路径挪开。

# 先确认键的类型和大致规模，再选择删除命令
redis-cli TYPE cache:user:1001
redis-cli MEMORY USAGE cache:user:1001

# 让键立即离开 keyspace，实际对象释放异步进行
redis-cli UNLINK cache:user:1001

# 返回 1 只说明键被摘除，不代表后台已经释放完全部内存
redis-cli EXISTS cache:user:1001

配置 lazyfree 时只打开匹配的路径

主动删除场景的核心动作仍然是调用 UNLINK。如果延迟来自过期或达到 maxmemory 后的淘汰，再分别考虑 lazyfree-lazy-expire 与 lazyfree-lazy-eviction。它们会改变对应路径的释放方式，不应因为“已经打开 lazyfree”就把所有删除都改成同步 DEL 或异步 UNLINK。

运行时可以用 CONFIG GET 查看当前值，用 CONFIG SET 做小范围试验；确认方案后还要把配置写入配置文件或执行合适的重写流程，因为运行时变更不会自动替代下次启动所使用的文件。

# 读取三个与后台释放相关的开关
redis-cli CONFIG GET lazyfree-lazy-expire lazyfree-lazy-eviction lazyfree-lazy-server-del

# 仅示例：先在低流量实例观察过期回收的影响
redis-cli CONFIG SET lazyfree-lazy-expire yes

# 试验结束后检查值，避免把临时设置误当成持久配置
redis-cli CONFIG GET lazyfree-lazy-expire

配置 lazyfree 后怎样判断是否真的缓解阻塞

判断是否有效要分三层。第一层看客户端看到的删除命令延迟；第二层看 Redis 主线程是否还被其他 O(N) 操作拖住；第三层看逻辑删除之后，used_memory 是否缓慢回落、后台线程是否长期繁忙。只看第一层，容易误判为“内存问题已经解决”。

可以先把延迟监控阈值设为业务能接受的毫秒数，再用 LATENCY LATEST 或慢日志观察删除高峰前后的变化。监控命令本身不是因果证明：如果主线程延迟下降、后台回收积压却持续增长，就要降低批量删除速度或拆分大对象，而不是继续提高删除并发。

# 只记录超过业务阈值的延迟事件，数值按业务 SLA 调整
redis-cli CONFIG SET latency-monitor-threshold 100

# 查看最近记录的延迟事件，关注删除高峰附近的变化
redis-cli LATENCY LATEST

# 观察逻辑删除后的内存趋势，不能把一次采样当作结论
redis-cli INFO memory | grep -E 'used_memory:|lazyfree_pending_objects:'

如果实例版本或部署形态没有提供你需要的指标，就用固定时间窗口记录 INFO memory、命令延迟和业务 QPS，比较灰度前后趋势。不要给后台队列设一个脱离机器 CPU、内存和对象大小的万能阈值。

批量删除大键的灰度清单

1. 先用 MEMORY USAGE 和数据结构规模抽样，按小批量执行 UNLINK。
2. 给删除任务限速，避免在后台回收尚未追平时继续制造大量释放工作。
3. 同时记录命令延迟、lazyfree_pending_objects、used_memory 和主机 CPU。
4. 若逻辑删除很快但内存长期不降，先确认后台队列、碎片和持久化压力，再决定是否扩大批次。
5. 需要回退时暂停清理任务即可；已经执行的 UNLINK 不可恢复，重要数据应先由业务侧完成备份或确认。

一句话总结：UNLINK 适合把大键释放移出 Redis 主线程，lazyfree 开关适合调整过期和淘汰路径；两者都必须和限速、内存趋势及延迟监控一起使用。

常见问题

UNLINK 返回后为什么内存还没有下降？

因为返回表示键已从 keyspace 摘除，实际对象回收在后台线程完成，回收速度还会受对象大小、CPU 和碎片影响。

打开 lazyfree-lazy-expire 后还需要主动使用 UNLINK 吗？

需要。前者针对自然过期路径，主动删除仍应由调用方选择 UNLINK，两条路径不是同一个开关。

能不能把 lazyfree 相关开关全部打开？

不建议直接全开。先按延迟来源选择路径，在低流量实例灰度，并观察后台回收压力是否超过机器承载能力。