Redis淘汰行为可通过INFO memory中evicted_keys计数器持续增长来识别，它是唯一可靠指标；SLOWLOG中EVAL/DEL命令耗时突增（>100ms）及INFO stats中expired_keys与evicted_keys同步上涨也是关键副作用信号。
如何从INFO memory和SLOWLOG中识别淘汰行为
Redis本身不直接记录“某key被LRU淘汰”这类日志，但淘汰动作会留下可观测痕迹。关键不是找“淘汰日志”，而是捕获淘汰发生的**副作用信号**：
-
INFO memory中的evicted_keys计数器——每次淘汰一个key就+1，是唯一可靠指标；持续增长说明策略正在生效 -
SLOWLOG GET里出现EVAL或DEL类命令耗时突增（>100ms），常因淘汰触发了大key清理或内存整理 -
INFO stats中expired_keys突增 +evicted_keys同步上涨，大概率是volatile-ttl或volatile-lru在起作用 - 注意：如果
evicted_keys为 0 但内存持续逼近maxmemory，说明策略没生效（比如配了noeviction）或写入已被拒绝（查rejected_commands）
用redis-cli + shell脚本做轻量级淘汰监控
不需要引入Prometheus也能快速落地告警，核心是定时采集并比对 evicted_keys 增量：
#!/bin/bash REDIS_CLI="redis-cli -h 127.0.0.1 -p 6379" KEY="redis:evict:counter" OLD=$( $REDIS_CLI GET $KEY 2>/dev/null || echo 0 ) NEW=$( $REDIS_CLI INFO memory | grep evicted_keys | cut -d: -f2 | tr -d '\r\n' ) <p>if [ "$NEW" -gt "$OLD" ]; then DELTA=$((NEW - OLD)) echo "$(date): $DELTA keys evicted in last cycle" | logger -t redis-evict</p><h1>这里可接 curl 发企业微信/钉钉告警</h1><p>fi $REDIS_CLI SETEX $KEY 300 $NEW
- 脚本每分钟执行一次，用
SETEX缓存上一轮值，TTL设为300秒防残留 - 别直接依赖
INFO的原始值做绝对判断——重启后evicted_keys归零，必须用增量 - 若发现单次
DELTA > 1000，大概率是批量淘汰开始，应同步检查mem_fragmentation_ratio是否 >1.8
为什么不能只看 evicted_keys 增长就发高危告警
单纯 evicted_keys 上涨不等于故障，它可能是健康缓存行为。真正危险的是**淘汰频率与业务写入节奏失配**：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在低QPS场景（evicted_keys 增长 >50 就值得人工介入——说明内存严重不足或策略错配
- 在高QPS缓存场景（>5万 ops/sec），
evicted_keys每分钟涨几千是正常的，此时要结合keyspace_hits / (keyspace_hits + keyspace_misses)看命中率是否跌破95% - 最危险的组合：
evicted_keys持续增长 +rejected_commands>0 —— 表明淘汰跟不上写入，noeviction已被触发或策略切换失败 - 老版本 Redis（MEMORY PURGE，
evicted_keys上涨后used_memory_rss不降，碎片会越积越多，需额外监控mem_fragmentation_ratio
在Grafana+Prometheus中配置淘汰告警的关键点
如果你用 Prometheus，redis_exporter 默认暴露 redis_memory_evicted_keys_total，但直接设阈值会误报。正确做法是：
- 用 PromQL 计算速率：
rate(redis_memory_evicted_keys_total[5m])，单位是“每秒淘汰数” - 告警规则示例：
rate(redis_memory_evicted_keys_total[5m]) > 10 and on(instance) redis_up == 1（每秒淘汰超10个且实例存活） - 必须加
and on(instance)关联redis_up，否则实例宕机时evicted_keys停滞会被误判为“无淘汰” - 不要忽略
redis_instance_info{role="master"}标签——从节点不会淘汰，只监控主节点 - 配套看
redis_memory_used_bytes / redis_memory_max_bytes，当该比值 >0.85 且淘汰速率 >5/s，才升级为P1告警
淘汰本身不是问题，问题是淘汰是否在按预期节奏发生。最容易被忽略的是：evicted_keys 增长缓慢但 used_memory_rss 居高不下，这往往意味着内存碎片卡死，而不是数据太多——此时切策略、删key都无效，得 MEMORY PURGE 或重启。
