用 redis-cli --stat -i 2 最省事，每2秒刷新一行，括号内“+N”即过去2秒淘汰次数；它基于 INFO memory 中 evicted_keys 差值计算，避免误读累计值。
直接用 redis-cli --stat -i 2 看每秒增量最省事
这个命令每 2 秒刷新一行，最后一列括号里的 +N 就是过去 2 秒新增的淘汰次数。比如输出 1705992954 (+57)，说明刚过去的 2 秒内发生了 57 次驱逐。它底层就是轮询 INFO memory 中的 evicted_keys 并做差值计算，不用写脚本、不依赖外部工具。
常见错误现象：只运行一次 redis-cli INFO memory | grep evicted_keys，看到 evicted_keys:12489 就以为“现在正在淘汰”，其实这只是累计总数，无法反映压力节奏。
- 必须加
-i参数指定间隔，否则默认每秒刷一次，但人眼跟不上跳变 - 别用
--latency或--bigkeys替代——它们不提供淘汰速率 - 云服务控制台里显示的
redis_evicted_keys_per_sec本质也是这么算的，只是封装了轮询逻辑
RedisInsight 里必须点 Rate 按钮才能看出真实压力
默认图表展示的是 evicted_keys 的累计值曲线，平缓上升看不出问题；只有点击图右上角的 Rate 按钮（或导出 CSV 后用时间戳算 delta），才会转换成每秒淘汰数。这时再叠加 used_memory_human 曲线，如果两者同步冲高（比如内存长期 >95% maxmemory，且每秒淘汰 >500 次），基本可断定淘汰已成常态。
容易踩的坑：没点 Rate 就下结论说“淘汰不严重”，结果线上请求延迟悄悄升高。因为累计值对短期尖峰完全不敏感。
- Rate 模式下的纵坐标单位是
keys/sec，不是个数 - 如果 Rate 图出现持续 >1000/sec 的平台段，说明主线程正被淘汰逻辑反复抢占
- 该图表不包含
eviction类型延迟，要补上这块得单独跑redis-cli --latency-history -i 1
写个简单循环脚本抓差值，适合告警集成
监控系统通常需要结构化数据，这时候就得自己取差值。核心逻辑就是每 N 秒执行一次 INFO memory，提取 evicted_keys 字段，和上一次的值相减。
示例 shell 片段（每 2 秒采样）：
last=0; while true; do
now=$(redis-cli INFO memory 2>/dev/null | grep "^evicted_keys:" | cut -d: -f2 | tr -d ' \r\n')
if [ -n "$now" ] && [ "$now" != "$last" ]; then
echo "evicted_per_sec=$((now - last))"
fi
last=$now; sleep 2
done注意点：
-
evicted_keys是整数，但 Redis 启动后可能为 0；首次采集时差值无意义，建议跳过前两次 - 如果
now为空（如连接失败、权限不足），脚本不能崩，要用2>/dev/null和[ -n "$now" ]做防护 - 别用
CONFIG GET maxmemory-policy的结果代替淘汰监控——策略配错（如noeviction）会导致evicted_keys永远为 0，但业务已在静默报错
别只盯 evicted_keys，顺手查 expired_keys 和碎片率
evicted_keys 上涨快，未必是内存真不够。如果 expired_keys 也在同步飙升，大概率是大量短 TTL key 到期被删，而不是淘汰策略在主动干预；反过来，如果 evicted_keys 涨得猛但 expired_keys 几乎不动，才说明策略确实在起作用。
另一个干扰项是内存碎片：mem_fragmentation_ratio > 1.5 时，used_memory_human 显示还有余量，但 used_memory_rss_human 已逼近物理内存上限，OS 不回收释放的页，导致 Redis 认为自己“没空闲内存”而频繁触发淘汰。
- 查过期键清理量：
redis-cli INFO stats | grep expired_keys - 查碎片率：
redis-cli INFO memory | grep mem_fragmentation_ratio - 大 key 会加剧碎片和淘汰频率，用
redis-cli --bigkeys扫描，一个 50MB 的 hash 就可能让一次淘汰卡住主线程几十毫秒
真正难判断的，是淘汰动作本身不报错、不打日志，只悄悄吃掉 CPU 时间片——你得靠 evicted_keys 的增速、cmd 吞吐下跌、instantaneous_ops_per_sec 骤降这三者交叉验证，才能确认它是不是正在拖慢整个实例。
