缓存雪崩需在应用层防御，而非依赖负载均衡器；因LB无法感知Redis健康状态、不能区分缓存命中与穿透请求，限流反而加剧DB压力；应通过应用内异常捕获、降级策略和健康探活实现精准防控。
缓存雪崩不是负载均衡器能解决的问题
Redis 本身不产生雪崩，雪崩是业务层面对 Redis 失效（如集群宕机、主从全挂、TTL 集中过期）时，大量请求穿透到下游数据库导致的连锁故障。负载均衡器（如 Nginx、HAProxy、云 LB）工作在 TCP/HTTP 层，它无法感知 Redis 是否健康、key 是否命中、连接是否超时——它只转发流量，不参与缓存逻辑。指望它“整形”雪崩流量，就像让快递分拣站替你判断包裹里是不是炸弹。
为什么在 LB 上做限流/降级反而可能加剧问题
常见误操作是在 Nginx 里对 /api/user 接口加 limit_req，以为能“削峰”。但问题在于：
- 缓存未命中和命中的请求对后端压力差异极大，而 LB 无法区分：一个命中 Redis 的请求耗时 0.2ms，一个打穿到 DB 的请求可能耗时 800ms —— 限流策略却一视同仁
- LB 的限流是全局或按 IP/URI 维度，无法关联 Redis 状态。当 Redis 已经不可用，LB 还在把请求均匀分给所有应用实例，等于加速压垮数据库
- 云厂商 LB（如 ALB、CLB）通常不支持基于自定义健康检查结果动态调整权重，无法实现“Redis 故障 → 自动降低该服务实例权重”的闭环
真正有效的流量整形必须发生在应用层
你需要在业务代码里做三件事，且顺序不能错：
- 用
try/catch包裹redis.get()，捕获ConnectionError、TimeoutError等底层异常，而不是等 HTTP 超时才反应 - 检测到 Redis 异常后，立即切换降级策略：返回本地缓存（
guava Cache）、静态兜底数据（fallback.json），或直接返回空响应（需前端兼容） - 启动后台线程调用
redis.ping()定期探活，并用AtomicBoolean或ConcurrentHashMap缓存健康状态，避免每次请求都探测
示例伪代码：
if (!redisHealth.get()) {
return getFallbackData(); // 不走 DB
}
String value = redis.get(key);
if (value == null) {
value = loadFromDB(key); // 此时才查库
redis.setex(key, 300, value);
}
return value;
如果非要 LB 参与，只能做极简兜底
仅建议在以下场景配置 LB 健康检查：
- 将应用实例的健康检查端点（如
/health）与 Redis 状态绑定：当 Redis 不可用时，主动返回 HTTP 503，让 LB 将该实例摘除 - 云 LB 支持自定义 TCP 健康检查时，可指向一个轻量脚本（如
redis-cli -h $REDIS_HOST ping &>/dev/null），但注意：该脚本必须超时短（≤1s）、无副作用、不引入额外依赖 - 绝对不要在 LB 层配置
retry或重试次数，否则 Redis 恢复瞬间会引发请求风暴
真正的雪崩防御不在网络设备上，而在你写 redis.get() 那行代码前的 if 判断里 —— 以及那个没人愿意写的 getFallbackData() 函数里。
