应盯住 expired_keys_total 的短时增速突变而非绝对值，如 30 秒内 rate 跃升至 300 且伴随 keyspace_misses 上升、ops 无增长、used_memory 骤降＞30%、mem_fragmentation_ratio＞1.5，结合 scan+ttl 探测 2–5 分钟内过期 key 分布。
盯住 expired_keys_total 的突增节奏，不是绝对值
单纯看 expired_keys_total 当前值没意义，它是个累计计数器。真正危险的是它在短时间内的增速变化——比如过去 1 分钟内每秒平均值突然从 5 跳到 300，且曲线呈阶梯式跃升，说明有批量 key 正在集中过期。
常见错误现象：rate(redis_expired_keys_total[5m]) > 200 这类固定阈值告警，在低峰期（如凌晨）极易误报；在高峰期又可能漏掉真实洪峰。
实操建议：
- 用
rate(redis_expired_keys_total[30s])替代分钟级窗口，捕捉秒级爆发 - 叠加条件：该突增必须伴随
redis_keyspace_misses_total同步上升，而instantaneous_ops_per_sec无明显增长——排除流量上涨干扰 - 若使用 redis-exporter，确保版本 ≥ v1.50，避免计数器翻转导致的 rate 计算失真
结合 used_memory 的分钟级骤降判断“刚失效”事件
used_memory 下降比命中率下跌更早暴露问题。Redis 在大批 key 真正被驱逐或过期清理后，内存会快速回落，这个信号往往比 keyspace_misses 暴涨早 10–20 秒。
关键不是“降了多少”，而是“怎么降”：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
used_memory在 60 秒内下降 >30%，且下降过程非平滑（有明显拐点），基本可判定刚经历一轮集中淘汰 - 同步检查
mem_fragmentation_ratio是否 >1.5 并持续爬升——碎片化会拖慢内存回收，放大雪崩延迟 - 对比
used_memory_peak和当前used_memory差值：若该差值从 1.8GB 快速收窄至 300MB，说明缓存层已严重失能
别信 --hotkeys，用 SCAN+TTL 批量采样“排队过期”的 Key
redis-cli --hotkeys 只反映访问频次，对“即将集体过期”的 key 完全无感。它不读 TTL，也不预判失效时间窗。
真正要探测的是未来 2–5 分钟内到期的 key 分布：
- 禁用
KEYS *，改用SCAN控制节奏：redis-cli --scan --pattern "user:*" --count 100 | xargs -I{} sh -c 'echo {}; redis-cli ttl {}' | awk '$2 > 0 && $2 - 业务写缓存时，主动把高危 key（如带短 TTL 的商品页）写入一个临时
zset，score 设为unix_timestamp + ttl，再用ZRANGEBYSCORE查未来 300 秒到期的 key 列表 - 采样频率控制在每 5 分钟一次，避免 SCAN 对主线程造成抖动
告警必须满足复合条件，单指标触发等于放任误报
生产环境里，所有只依赖单一指标的雪崩告警规则都不可靠。真正有效的前哨预警必须同时满足至少两个强相关信号。
推荐 Prometheus 告警规则组合（需 redis-exporter v1.50+）：
-
rate(redis_expired_keys_total[2m]) > 500—— 2 分钟内过期速率超 500/s avg_over_time(redis_keyspace_hits_total[1m]) / (avg_over_time(redis_keyspace_hits_total[1m]) + avg_over_time(redis_keyspace_misses_total[1m])) —— 1 分钟命中率跌破 50%- 二者必须同时成立才触发一级预警，缺一不可
最易被忽略的点是：rate() 函数对计数器重置极其敏感，而 Redis 实例重启、主从切换都会导致 expired_keys_total 归零。不加兜底校验的 rate 计算，会在运维操作后连续误报半小时以上。
