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

info keyspace无法反映淘汰情况，因其仅统计存活key数量，不区分已过期未删除或已被淘汰的key，且不记录evicted_keys等关键淘汰指标。

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

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

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

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

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

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

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

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

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

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

先确认所有 master 节点的 maxmemory-policy 是否一致（CONFIG GET maxmemory-policy），避免混用 volatile-lru 和 allkeys-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，说明刚经历过一波大回收，主线程可能被阻塞过

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

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