Redis雪崩本质是缓存失效引发的数据库穿透与级联故障，需通过缓存设计、熔断策略（如Sentinel慢调用比例+异常比例双指标）、降级动作（可预测兜底）协同防御，而非仅依赖Hystrix固定阈值熔断。
Redis雪崩不是Redis自身崩溃，而是缓存层大面积失效后，海量请求穿透到数据库，引发下游服务连锁超时、线程池打满、最终触发熔断器开启——这时候单纯配个 fallback 没用，得从缓存设计、熔断策略、降级动作三个层面协同防御。
Redis雪崩发生时，Hystrix熔断器为什么容易误判？
Hystrix默认依赖滑动窗口统计错误率，而Redis雪崩初期往往表现为大量 TimeoutException 或 JedisConnectionException，但这些异常可能混杂着数据库慢查询、连接池耗尽等真实故障。Hystrix无法区分“是缓存没命中的正常穿透”，还是“数据库已扛不住的危险信号”。
- 滑动窗口太小（如默认10秒）：雪崩刚爆发就触发熔断，但此时DB可能只是瞬时抖动，还没真正崩溃
- 错误率阈值固定（如50%）：缓存预热期或大促压测时，穿透率天然高，容易把合理流量当故障
- 不感知下游负载：DB CPU 95% 和 30% 下，Hystrix 的
circuitBreaker.errorThresholdPercentage行为完全一样
Sentinel 的熔断规则怎么适配 Redis 雪崩场景？
Sentinel 支持基于慢调用比例 + 异常比例双指标熔断，更适合 Redis 雪崩这种“响应延迟先于错误爆发”的特征。关键不是等 DB 报错，而是当缓存穿透导致 DB 响应普遍变慢时就提前干预。
- 配置慢调用阈值
slowRatioThreshold=0.3（30% 请求 RT > 800ms），比只看错误率更早预警 - 熔断时间窗设为
timeWindow=60秒，避免雪崩恢复期过长影响业务 - 必须配合系统规则（
SystemRule）：当应用 CPU > 80% 或 Load > 3 时，自动降级非核心缓存读取路径
示例规则片段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
FlowRule rule = new FlowRule("cache:getUser")
.setGrade(RuleConstant.FLOW_GRADE_RT)
.setCount(800) // 慢调用阈值 ms
.setSlowRatioThreshold(0.3)
.setTimeWindow(60);
@SentinelResource 的 blockHandler 里不能只返回 null
很多团队在 blockHandler 里直接 return null 或空对象，结果上游服务因 NPE 或逻辑分支错乱继续失败，反而加剧雪崩。降级必须可预测、可审计、有兜底能力。
- 对读操作：返回本地缓存副本（如 Caffeine）、降级为默认值、或走异步补偿（记录日志+MQ重试）
- 对写操作：禁止在
blockHandler中执行 DB 写入，改用消息队列异步落库，避免阻塞主线程 - 必须记录明确 traceId 和降级原因（如
"redis_unavailable_fallback"），否则监控里看不到降级是否真生效
Redis 雪崩期间，Sentinel 控制台里最该盯住的三个指标
别只看“QPS 下跌”或“Block 数上升”，那只是结果。真正要实时盯的是：
-
rt（平均响应时间）：突破 800ms 且持续 30 秒，说明穿透已开始冲击 DB -
exceptionQps：不是总异常数，而是每秒新增异常数，突然跳涨 5 倍以上是雪崩明确信号 -
blockedQps / passQps比值：如果稳定在 0.8 以上，说明 Sentinel 已进入强保护模式，需人工确认是否要临时放宽规则
这些指标在 Sentinel Dashboard 的「实时监控」页每秒刷新，比日志排查快一个数量级。但注意：控制台本身依赖 Redis 存储规则，雪崩时它也可能失联——务必提前配置好 Nacos 或 Apollo 作为规则持久化源。
