Redis如何避免慢查询风暴，SLOWLOG分析大Key驱逐影响

Redis卡顿的“真凶”往往不是慢命令本身，而是内存触顶后同步驱逐大Key导致主线程阻塞——即使SLOWLOG里全是SET/DEL，实际瓶颈在于驱逐过程；通过启用lazyfree-lazy-eviction、将DEL替换为UNLINK、用--bigkeys定期扫描隐患、并依业务访问特征合理选择allkeys-random或allkeys-lfu淘汰策略，可显著缓解甚至根治慢查询风暴，但若后台异步队列持续积压，还需考虑实例拆分或硬件升级。

为什么 SLOWLOG 里全是 SET / DEL 却还卡？

这不是命令本身慢，而是 Redis 在执行这些命令前，被迫同步驱逐（evict）key 来腾内存。当 maxmemory 触顶、又配置了 allkeys-lru 或 volatile-lru 这类需要采样+比对的策略时，每次写入都可能触发一轮淘汰逻辑——尤其遇到 bigkey，释放内存过程会阻塞主线程，直接拖慢后续所有命令。

典型现象：SLOWLOG get 10 显示大量 SET、DEL、HSET 耗时超 10ms，但业务没改，QPS 也没突增；同时 INFO memory 中 used_memory_human 稳定贴近 maxmemory_human。

用 redis-cli --bigkeys 快速定位隐患 key

别等线上报警才扫，定期跑一次就能暴露风险点。注意它默认只采样 0.01% 的 key，对大实例要调低采样间隔避免卡顿：

• redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.001（更细粒度扫描）
• 重点看输出中 Biggest string、Biggest hash 行末的字节数，超过 10KB 就该警惕
• 如果发现 list 或 zset 元素数 > 1w，即使单个元素小，也属于逻辑 bigkey，LRANGE/ZRANGE 容易触发慢查

lazyfree-lazy-eviction yes 是关键止血项

Redis 4.0+ 默认淘汰是同步释放内存，遇到 bigkey 就卡死。开启后台异步驱逐后，主线程只做标记，真正释放交由 bio 线程处理：

• 确认版本：redis-cli INFO server | grep redis_version ≥ 4.0
• 启用配置：CONFIG SET lazyfree-lazy-eviction yes（临时生效），并写入 redis.conf
• ⚠️ 注意：这仅对淘汰策略触发的删除生效，不覆盖 UNLINK 或显式 DEL 行为
• 若业务已大量使用 DEL 删除 bigkey，应主动替换成 UNLINK（异步删）

淘汰策略选 allkeys-random 还是 allkeys-lfu？

取决于你的数据访问模式是否真有“热度区分”：

• allkeys-random：完全跳过采样比对，驱逐开销恒定极低，适合缓存命中率本就不高、或写多读少的场景（如 session 存储）
• allkeys-lfu：需开启 lazyfree-lazy-eviction 才安全，否则高频 LFU 计数器更新+衰减+采样会加重 CPU 压力；适合能明确分出冷热数据的业务（如商品详情页缓存）
• 绝对避开 volatile-lru + 大量短过期 key：过期 key 清理和淘汰逻辑叠加，双重阻塞风险

真正容易被忽略的是：哪怕开了 lazyfree，如果淘汰压力持续高于后台线程处理能力，bio 线程队列会堆积，INFO stats 中 lazyfree_pending_objects 会持续上涨——这时得靠拆实例或升配来根治。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis如何避免慢查询风暴，SLOWLOG分析大Key驱逐影响》文章吧，也可关注golang学习网公众号了解相关技术文章。