expired_keys单独看无预警价值，因其为累计值；须结合rate(expired_keys[1m])与keyspace_misses突增、evicted_keys同步飙升及QPS未升等指标联合判断雪崩风险。
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 版本与对应配置是否生效，否则告警规则再准也没用。
