登录
首页 >  数据库 >  Redis

Redis集群数据过期淘汰怎么查?INFO keyspace监控方法

时间:2026-05-27 09:43:15 191浏览 收藏

Redis集群中数据过期与内存淘汰问题无法通过INFO keyspace准确识别,因其仅统计存活key数量,完全忽略已过期未清理或已被强制驱逐的key,更不反映evicted_keys等关键淘汰指标;真正有效的排查需聚焦INFO stats中的evicted_keys(内存不足触发)与expired_keys(过期机制触发)增量对比,结合各节点maxmemory配置、内存使用率及峰值内存分析,并警惕客户端误设超长TTL导致LRU失效等隐蔽陷阱——这些隐患在key数量表面稳定时悄然恶化性能,唯有逐节点采集动态指标并关联业务场景才能精准定位根因。

Redis集群数据过期淘汰怎么排查_通过INFO keyspace监控各节点淘汰情况

INFO keyspace 不能直接反映淘汰情况,它只统计当前存活 key 的数量,对已过期未访问、已被淘汰的 key 完全不体现。 想靠 INFO keyspace 发现“哪个节点 key 少了”,基本是徒劳的。

为什么 INFO keyspace 对淘汰排查无效

INFO keyspace 返回的是每个 db 的键数量(如 db0:keys=123,expires=45,avg_ttl=3600),但它:

  • 不区分“已过期但尚未被惰性/定期删除”的 key —— 这些仍会计入 keys 总数
  • 完全不记录“因内存不足被 evicted_keys 清掉”的 key —— 淘汰后它们从字典里彻底消失,keys 值已扣减,但你无从知道是自然过期还是被踢走
  • 集群模式下各节点 INFO keyspace 独立返回,但数值波动可能源于迁移、故障转移或客户端路由偏移,和淘汰无关

真正该盯的指标:evicted_keys 和 expired_keys 差值

淘汰行为在 INFO stats 中有明确计数器,必须结合时间维度看增量:

  • evicted_keys:仅由内存淘汰策略触发,每次踢一个 key 就 +1
  • expired_keys:仅由过期机制触发(惰性+定期),每次真正删掉一个过期 key 就 +1
  • 如果某节点 evicted_keys 在业务高峰每秒涨 > 500,而 expired_keys 增速平缓 → 大概率是 maxmemory 不足,正在高频淘汰
  • 如果两者同步飙升(比如都突增 1000+/sec),更可能是 TTL 集中设置错误,导致大量 key 同时进入定期删除队列

实操建议用脚本每 2 秒抓一次差值:

redis-cli -h node1 -p 6379 INFO stats | grep -E "evicted_keys|expired_keys"

集群环境下如何定位具体节点是否异常淘汰

Redis 集群本身不聚合淘汰数据,必须逐个节点采集并比对:

  • 先确认所有 master 节点的 maxmemory-policy 是否一致(CONFIG GET maxmemory-policy),避免混用 volatile-lruallkeys-lfu
  • 对每个 master 执行:
    redis-cli -h $HOST -p $PORT INFO memory | grep -E "used_memory_human|maxmemory_human"
    ,检查 used_memory_human 是否长期 > 95% maxmemory_human
  • 再执行:
    redis-cli -h $HOST -p $PORT INFO stats | grep -E "evicted_keys|expired_keys"
    ,挑出 evicted_keys 增速明显高于其他节点的那个
  • 重点查该节点的 used_memory_peak_human:若远高于当前 used_memory_human,说明刚经历过一波大回收,主线程可能被阻塞过

容易被忽略的陷阱:客户端误设超长 TTL 导致 LRU 失效

比如某服务写入配置 key 时用了 SETEX config:timeout 315360000 "30s"(10 年 TTL),这个 key 在 volatile-lru 下永远不会被淘汰,却长期霸占 LRU 链表头部,把真实热 key 挤出去。现象是:

  • evicted_keys 持续上涨,但 INFO keyspace 显示 expires 数量很少
  • MEMORY USAGE 查几个疑似热 key,发现内存占比低;但用 OBJECT FREQ 查访问频次,发现它们几乎不被访问
  • 根本原因不是内存不够,而是“伪热 key”污染了淘汰队列

这类问题不会在 INFO keyspace 里暴露任何异常,只会让你盯着“key 数量稳定”就误判为一切正常。

文中关于的知识介绍,希望对你的学习有所帮助!若是受益匪浅,那就动动鼠标收藏这篇《Redis集群数据过期淘汰怎么查?INFO keyspace监控方法》文章吧,也可关注golang学习网公众号了解相关技术文章。

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>