evicted_keys本身是累计值，必须结合采集间隔、maxmemory-policy配置及used_memory_human/maxmemory比值交叉判断淘汰是否真在发生；单看数值无意义，需监控其单位时间增量、内存水位与碎片率三者联动信号。

evicted_keys 是唯一能确认“Redis 正在踢人”的硬指标，但它本身是累计值，直接看数字毫无意义——必须结合采集间隔、策略配置和内存水位交叉判断。

怎么用 INFO memory 快速确认淘汰是否真在发生

运行 redis-cli INFO memory | grep evicted_keys，如果输出是 evicted_keys:0，不代表安全：它只说明“自启动以来没触发过淘汰”，但可能因为策略是 noeviction，此时内存满会直接报错 OOM command not allowed when used memory > 'maxmemory'。所以必须连着查策略：

• 先跑 redis-cli CONFIG GET maxmemory-policy，确认不是 noeviction
• 再查 redis-cli INFO memory | grep -E "used_memory_human|maxmemory|evicted_keys"，看三者关系
• 如果 used_memory_human 已接近 maxmemory（比如 >95%），且 evicted_keys 在缓慢上涨，说明淘汰已成常态

为什么单次查 evicted_keys 基本没用

evicted_keys 从不归零，也不重置，它只加不减。线上出问题时，你真正要盯的是“这一秒涨了多少”。例如：

• 某实例当前 evicted_keys:1024，但过去 60 秒没变 → 淘汰早已停了
• 另一实例同一时刻 evicted_keys:1032，但 1 秒前是 1000 → 这一秒淘汰了 32 个 key，得立刻查热点

用 redis-cli --stat 可以实时看到最后一列的每秒增量，比手动 grep 更快，但注意它只显示差值，不存历史。

Redis Skill - 高性能缓存管理

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

下载

容易被忽略的干扰项：evicted_keys 上涨 ≠ 内存真不够

有些上涨是人为操作导致的，和内存压力无关：

• 客户端批量执行 FLUSHDB 或 DEL，也会让 evicted_keys 增长（Redis 把这类删除也计入该计数）
• 如果 expired_keys 同步飙升，大概率是大量 key 集中过期，不是淘汰策略在干活
• 看 keyspace_misses：如果它突然暴涨 + evicted_keys 微增，可能是缓存穿透把空值/错误值写进去了，占了内存又没用

真正反映内存压满的信号是 used_memory_peak_human 长期贴近 used_memory_human，而不是 evicted_keys 多大。

生产环境必须盯住的三个组合信号

单独一个 evicted_keys 数字，什么也说明不了。你要同时观察：

• used_memory_human / maxmemory 比值 → 决定淘汰是否“不得不做”
• evicted_keys 在固定时间窗口（如 5 秒）内的差值 → 决定淘汰是否“正在高频发生”
• mem_fragmentation_ratio（比如 >1.5）→ 如果 RSS 远大于 used_memory，说明碎片严重，淘汰后内存还回不去，压力会持续

这三个数不联动看，就容易把误配策略当成内存瓶颈，或者把真实爆内存当成偶发抖动。