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，说明碎片严重，淘汰后内存还回不去，压力会持续
这三个数不联动看，就容易把误配策略当成内存瓶颈，或者把真实爆内存当成偶发抖动。
