info memory 可通过used_memory短时骤降超30%、mem_fragmentation_ratio>1.5持续上升、used_memory_peak与当前值差值快速收窄等异常波动识别雪崩前兆，配合keyspace_misses突增斜率与预热后失效峰分布判断风险。
怎么用 INFO memory 看出雪崩前兆
Redis 缓存雪崩往往不是突然发生的，而是先有征兆：缓存命中率断崖下跌、内存使用量剧烈波动、大量 key 集中失效——这些都会在 INFO memory 输出里留下痕迹。关键不是“有没有告警”，而是“能不能从波动模式里读出异常”。
-
used_memory短时间（比如 1 分钟内）下降超过 30%，大概率是大批 key 同时过期或 flush 导致的“缓存清空”；如果紧接着keyspace_misses暴涨，基本可以确认雪崩正在发生 -
mem_fragmentation_ratio> 1.5 且持续上升，说明内存分配碎片化严重，可能伴随大量 key 删除 + 新写入，容易诱发 OOM 或延迟抖动，间接放大雪崩影响 - 不要只看绝对值，要监控
used_memory_peak和当前used_memory的差值——如果这个差值快速收窄（比如从 2GB 缩到 200MB），说明 Redis 刚经历一轮大规模淘汰，缓存层已严重失能
为什么光盯 keyspace_hits/keyspace_misses 不够
命中率数字本身很“诚实”，但太晚了。等 keyspace_hits / (keyspace_hits + keyspace_misses) 掉到 70% 以下，数据库早就开始排队了。真正有用的，是它的“变化斜率”和“分布偏差”。
- 每 10 秒采一次命中率，连续 3 次下降 >15% 就该触发一级预警，比阈值告警快 2–3 倍
- 如果
keyspace_misses在某秒内突增 5 倍以上，而同一时段instantaneous_ops_per_sec没明显增长，说明 miss 是集中爆发的（比如定时任务批量删 key），不是流量自然上涨 - 注意区分“冷 key miss”和“热 key miss”：前者是正常行为，后者才是风险信号。可通过
redis-cli --hotkeys（Redis 7.0+）或SCAN+OBJECT FREQ辅助判断
用 redis-cli 写个轻量级轮询脚本防漏报
别一上来就上 Prometheus + Grafana。很多团队卡在“监控还没搭好，雪崩先来了”。一个 20 行以内的 shell 脚本，就能守住第一道防线。
#!/bin/bash
REDIS="redis-cli -h 127.0.0.1 -p 6379"
while true; do
mem=$( $REDIS info memory | grep used_memory: | cut -d: -f2 | tr -d '\r\n' )
hits=$( $REDIS info stats | grep keyspace_hits: | cut -d: -f2 | tr -d '\r\n' )
misses=$( $REDIS info stats | grep keyspace_misses: | cut -d: -f2 | tr -d '\r\n' )
rate=$(awk "BEGIN {printf \"%.0f\", $hits*100/($hits+$misses+1)}")
if [ "$rate" -lt 85 ] && [ "$misses" -gt 1000 ]; then
echo "$(date): LOW HIT RATE $rate%, MISSES $misses, MEM $mem" | mail -s "Redis Alert" ops@example.com
fi
sleep 10
done
- 脚本里加了
+1防除零，mail可换成curl调企业微信/钉钉 webhook - 不要用
INFO all——它锁整个 Redis 实例，高并发下反而拖慢服务；分拆调用INFO memory和INFO stats更安全 - 注意
keyspace_misses是累计值，必须做差值计算（记录上一次值），否则无法识别“突增”
最容易被忽略的盲区：缓存预热失败后的“假稳定”
上线新服务或扩容节点后，常有人跑完预热脚本就以为万事大吉。但预热数据如果没设随机 TTL，或者预热 key 全部落在同一个 slot（Redis Cluster 场景），就会在几小时后集体过期——此时监控看到的内存曲线平稳、QPS 正常，命中率也还行，直到那个整点时刻，所有请求同时穿透。
- 预热时强制加偏移：
redis.setex(key, base_ttl + random.randint(0, 600), value)，哪怕只是 +0~10 分钟，也能打散失效峰 - 检查预热 key 的 slot 分布：
redis-cli --cluster check或对 key 批量执行CLUSTER KEYSLOT，避免热点集中在少数节点 - 上线后头 2 小时，手动查一次
redis-cli --hotkeys，确认预热 key 确实被访问到了——没被访问的预热，等于没预热
