什么是雪崩效应（Avalanche Effect）
一句话定义
一个很小的局部故障，被系统不断放大，最终导致整个系统级联崩溃。
就像一块小石头引发整座雪山崩塌。
生活化比喻
高速公路上：前车轻踩一脚刹车 → 后车跟着刹 → 再后面刹得更狠 → 最终几十辆车全停死。
最初只是个小动作，最终却堵死整条高速。 这就是雪崩。
互联网系统里的典型雪崩链路
MySQL 变慢（20ms → 2s）
│
▼
库存服务大量线程等待
│
▼
Tomcat 线程池被占满
│
▼
订单服务调用超时
│
▼
客户端疯狂重试 → 流量翻倍
│
▼
数据库更慢 / Redis 连接耗尽 / MQ 堆积
│
▼
CPU 100% → OOM
│
▼
整个系统崩溃1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
放大器：无隔离 + 无限等待 + 无脑重试 = 局部故障变全站故障。
微服务里的雪崩
A → B / C / D1
若 D 挂了、A 一直等 D 返回 → A 线程被占满 → A 挂 → 依赖 A 的所有服务也挂 → 全站不可用。
8 种防雪崩措施
| 手段 | 作用 |
|---|---|
| 超时（Timeout） | 不无限等待，例如 Feign 500ms 超时快速失败 |
| 熔断（Circuit Breaker） | 下游连续失败就断开，快速返回「系统繁忙」 |
| 限流（Rate Limiting） | 超过承载能力的请求直接拒绝，保护系统 |
| 降级（Fallback） | 挂了返回兜底数据/缓存，保住核心流程 |
| 缓存随机 TTL | ttl = 3600 + Random(0~600)，避免同时失效 |
| 请求隔离 | 订单/库存/支付各用独立线程池，故障不互相拖累 |
| 多级缓存 | 浏览器 → CDN → Nginx → Caffeine → Redis → MySQL 层层缓冲 |
| 重试要有限制 | 限次数 + 指数退避 + 随机抖动，避免同时重试压垮下游 |
与相关概念的区别
| 概念 | 含义 | 典型场景 |
|---|---|---|
| 雪崩效应（Avalanche） | 一个故障引发连锁反应，全站瘫痪 | DB 变慢拖垮整条链路 |
| 缓存雪崩（Cache Avalanche） | 大量缓存同时失效，DB 瞬时被打爆 | TTL 全设成一样 |
| 缓存击穿（Cache Breakdown） | 单个热点 Key 失效，请求全打 DB | 热门商品缓存过期 |
| 缓存穿透（Cache Penetration） | 查不存在的数据，永远绕过缓存打 DB | 恶意刷不存在的 ID |
本质与核心防御思路
本质：局部故障 + 缺乏隔离/限流/熔断/降级 → 被无限放大成级联故障。
防御核心：隔离故障、限制影响范围、快速失败、保护关键资源。
高并发系统的可用性，从来不是「不出问题」，而是「出了问题也炸不穿」。