怎样通过Redis监控指标预警缓存雪崩风险_重点关注Expired

expired_keys单独看无预警价值，因其为累计值；须结合rate(expired_keys[1m])与keyspace_misses突增、evicted_keys同步飙升及qps未升等指标联合判断雪崩风险。

怎样通过redis监控指标预警缓存雪崩风险_重点关注expired_keys指标

expired_keys 是雪崩前最该盯的指标之一，但它单独看毫无意义——必须结合时间窗口、增长斜率和业务上下文才能预警。

为什么只查 `expired_keys` 会误判

Redis 的 expired_keys 是一个累计计数器（从启动开始累加），它不反映“当前是否正在集中过期”，只告诉你“历史上总共删过多少个过期 key”。直接用 redis-cli info stats | grep expired_keys 看到的数字，可能是几百万，也可能是刚重启后的 0，完全无法判断风险。

真正要关注的是它的变化速率，即单位时间内的新增量：

用 rate(redis_expired_keys_total[1m])（Prometheus）或手动差值法计算每秒增量，才是有效信号
若过去 60 秒内 expired_keys 增加了 5000+，且此前 5 分钟平均值仅 20/秒，说明有洪峰
但若这 5000 是因刚执行了 FLUSHDB 或 EXPIRE 批量操作导致，则属于人工干预，非雪崩前兆

如何用 `redis-cli` 快速验证 `expired_keys` 是否异常突增

没有 Prometheus 时，靠 shell 脚本轮询也能守住第一道防线。以下命令可每 5 秒采样一次，连续跑 2 分钟，观察趋势：

for i in {1..24}; do
  now=$(redis-cli info stats | grep expired_keys | cut -d: -f2 | tr -d '\r\n')
  echo "$(date +%s): $now"
  sleep 5
done | awk '{if(NR==1) first=$2; else print $1, $2-first; first=$2}'

输出类似 1748183220 4820 表示这 5 秒内新增 4820 个过期 key——超过 300 就该立刻查业务写入逻辑。

注意点：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

不要在高峰期全量 SCAN 配合 TTL 查“哪些 key 即将过期”，那会阻塞主线程；抽样用 SCAN COUNT 1000 MATCH "product:*" 更安全
expired_keys 只统计被实际删除的 key 数，惰性删除（访问时才清理）不会计入，所以它偏保守——看到突增，说明雪崩已经发生了一部分
如果 evicted_keys 同步飙升，说明内存压力叠加过期洪峰，风险等级升为 P0

`expired_keys` 和 `keyspace_misses` 必须联合看

单看 expired_keys 上涨，可能是预热后主动淘汰；单看 keyspace_misses 上涨，可能是缓存穿透。两者同步跳升，才是雪崩典型特征。

实操中建议盯这两个组合信号：

keyspace_misses 在 1 分钟内增长 > 300%，且 keyspace_hits 同步下降 > 70%
expired_keys 对应时间段增量 ≥ keyspace_misses 增量的 60%（说明大部分 miss 来自 key 过期，而非根本没写入）
同时检查 instantaneous_ops_per_sec 是否未明显上升——若 QPS 没涨但 miss 暴涨，基本可排除流量突增，锁定为缓存层失效

这时候再翻应用日志找 cache miss rate: 100% 类语句，基本就是铁证。

容易被忽略的配置陷阱：active-expire-effort 和 lazyfree

即使你加了随机 TTL，expired_keys 曲线仍可能突兀跳升——问题常出在 Redis 自身清理策略上。

关键配置项影响如下：

active-expire-effort 1（默认）：每 100ms 最多扫描 20 个 key，面对每秒上千过期 key 时，清理严重滞后，大量 key 堆积到惰性删除阶段，等第一次访问才触发，造成延迟毛刺
lazyfree-lazy-expire yes（Redis 7.0+）：让定期删除阶段的内存回收异步化，避免主线程卡住；但它对惰性删除无效——用户访问过期 key 时，仍会同步 unlink，这点极易被忽略
旧版本 Redis（lazyfree-lazy-expire，若又没开 maxmemory-policy allkeys-lru 等淘汰策略，过期 key 会一直占内存，直到被访问才删，expired_keys 计数器反而“失真”

所以监控 expired_keys 时，务必确认 Redis 版本与对应配置是否生效，否则告警规则再准也没用。