缓存雪崩常在凌晨三点爆发，因大量key设相同过期时间且在低峰期批量预热或上线，导致redis集中失效、数据库瞬间承压；需监控expired_keys、evicted_keys及命中率等指标预警。
为什么缓存雪崩总在凌晨三点爆发
因为大量 key 被设置了相同 expire 时间，又恰好在低峰期批量预热、上线或定时任务触发，导致 Redis 在某个时间点集中失效。数据库瞬间承接全部请求，连接池打满、慢 SQL 堆积、RT 暴涨——而你收到告警时，系统已经卡死。
用 redis-cli --hotkeys 抓不到雪崩前兆？那是没开监控采样
redis-cli --hotkeys 本身不实时，它依赖 Redis 的 INFO commandstats 和内置采样器，必须先启用：
- 在
redis.conf中确认开启latency-monitor-threshold 100（单位 ms，建议设为 50~100） - 确保
maxmemory-policy不是noeviction，否则过期 key 清理会延迟，掩盖真实失效节奏 -
redis-cli --hotkeys只能反映“当前最热”，对“即将集体过期”的 key 完全无感——它不看 TTL，只看访问频次
真正要盯的是 expired_keys 和 evicted_keys 这两个指标，它们藏在 INFO stats 输出里，每秒突增 500+ 就该拉响一级预警。
Prometheus + Grafana 监控必须暴露的 3 个关键指标
别只盯着 redis_up 或 redis_connected_clients，雪崩前最敏感的信号来自这三项：
-
redis_keyspace_hits_total/redis_keyspace_misses_total：比值跌破 0.7 且misses持续上升 → 大量 key 正在失效或未命中 -
redis_expired_keys_total：过去 5 分钟内每秒平均值 > 200，且曲线呈阶梯式跳升 → 典型错峰失败，有批量 key 同时到期 -
redis_db_keys（按 db 维度）：某 db 的 key 总数在 2 分钟内下降超 30% → 可能刚执行了FLUSHDB或大批量EXPIRE生效
示例 PromQL（用于 Grafana 面板）：rate(redis_expired_keys_total[5m]) > 200(redis_keyspace_hits_total / (redis_keyspace_hits_total + redis_keyspace_misses_total))
光看指标还不够：得知道哪些 key 在“排队过期”
Redis 本身不提供“即将过期 key 列表”，但可通过以下方式低成本探测：
- 用
SCAN配合TTL批量采样（避免阻塞）：redis-cli --scan --pattern "user:*" | head -n 1000 | xargs -I{} sh -c 'echo {} ; redis-cli ttl {}' | grep -E "^[0-9]+$" | sort -n | head -n 10 - 在业务写缓存时，主动记录“高危 key”到一个临时
zset，score 设为current_timestamp + ttl，定期用ZRANGEBYSCORE查未来 5 分钟内到期的 key - 注意：不要在生产环境跑
KEYS *，它会阻塞主线程；SCAN也要控制COUNT参数（建议 ≤ 100），否则仍可能拖慢实例
真正难防的不是“已过期”，而是“过期时间被硬编码成常量”——比如所有商品详情都设 EXPIRE 3600，上线后一小时整集体消失。这种问题不会出现在监控图表里，只能靠代码扫描和 CR 卡点。
