Redis不自动触发雪崩预案,需通过OPS突增+拒绝连接、待过期key占比>60%且集中于1–2分钟内、缓存命中率1分钟内从99%骤降至<40%等组合信号识别;推荐redis-exporter+Prometheus实现前哨预警。

Redis 本身不会、也不应该“自动触发缓存雪崩的预案”——雪崩是故障现象,不是可主动触发的机制。所谓“自动触发预案”,本质是监控系统在检测到雪崩前兆(如大量 key 同时过期、后端 DB 突增压力、Redis 命中率断崖下跌)时,联动执行降级或保护动作。
如何识别缓存雪崩的真实信号
靠单一指标(比如 keys * 数量)完全不可靠。真正有效的判断依据是组合信号:
-
redis-cli info stats | grep -E "instantaneous_ops_per_sec|rejected_connections":OPS 突增 + 拒绝连接,说明请求已压垮 Redis 或下游 -
redis-cli info keyspace | grep -o "expires:[0-9]*":某 db 中即将过期的 key 占比 > 60%,且集中在未来 1–2 分钟内(需配合业务 TTL 分布分析) - 应用层
cache_hit_ratio在 1 分钟内从 99% → 低于 40%,且db_load_5m同步飙升 —— 这比 Redis 自身指标更早暴露问题 - 注意:
expired_keys计数器只统计已被惰性/定期删除的实际过期数,不能反映“待过期洪峰”,必须结合业务 key 的ttl批量采样预估
用 redis-exporter + Prometheus 做雪崩前哨预警
开源方案里最轻量可控的是 redis-exporter 搭配 Prometheus 告警规则,而非监听 Redis 日志或轮询 INFO:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 部署
redis-exporter时加参数--redis.addr=redis://:6379和--web.listen-address=:9121,确保能采集redis_keyspace_hits/redis_keyspace_misses - Prometheus 告警规则示例(非全量):
groups:
- name: redis-snowflake
rules:
- alert: HighExpiredKeysInWindow
expr: sum by (addr) (rate(redis_expired_keys_total[2m])) > 500
for: 1m
- alert: CacheHitRateDrop
expr: avg_over_time(redis_keyspace_hits_total[1m]) /
(avg_over_time(redis_keyspace_hits_total[1m]) + avg_over_time(redis_keyspace_misses_total[1m])) < 0.5
for: 45s这两个规则要同时满足才发高优告警,避免误触。注意 rate() 对计数器重置敏感,生产环境建议用 redis_exporter v1.50+ 版本(修复了部分指标翻转 bug)。
预案执行必须绕过 Redis,直接作用于应用层
任何“让 Redis 自己限流/熔断”的想法都违背设计原则。Redis 没有内置熔断器,强行用 CONFIG SET maxmemory-policy noeviction 反而会让 OOM 更快发生:
- 正确做法是:告警触发后,调用应用服务的降级开关接口,例如
POST /api/v1/feature-toggle?name=cache.enabled&value=false - 该接口应原子更新共享配置(如 Consul/KV 或本地
AtomicBoolean),所有实例 3 秒内生效,跳过 Redis 直连 DB 并启用本地 Caffeine 缓存(TTL 设为 10s 防穿透) - 严禁在预案中执行
FLUSHDB或KEYS类命令 —— 这些操作会阻塞主线程,加剧雪崩 - 如果用 Spring Cloud,优先走
@ConditionalOnProperty("cache.fallback.enabled")控制 Bean 加载,而不是运行时修改CacheManager
真正的难点不在监控链路搭建,而在于业务方能否提供准确的 key 过期分布画像,以及降级开关是否真的能不依赖 Redis 完成状态同步。这两点漏掉任何一个,预案就只是纸上逻辑。

















