一句话定义： 过载保护（Load Shedding）是系统在负载超过自身处理能力时，主动、有选择地丢弃或降级一部分请求，用“少做一点”换取“整体不崩”的机制。
为什么不能“一起慢一点”
很多人直觉上觉得：忙不过来就慢点处理，排队总比拒绝好。
但排队系统有个残酷特性：当利用率逼近上限，等待时间不是线性增长，而是急剧上升。餐厅坐满时，多来一桌不会让每桌只慢一点；它会形成越排越长的队伍，让每位客人都等到心态崩溃。
服务端也是这样。延迟一旦拉高，连锁反应就来了：客户端超时 → 自动重试 → 实际请求量翻倍 → 队列更长 → 连接数和内存被占满 → 连本来能秒回的请求也开始超时。这就是雪崩。最后所有请求都得不到有效结果，可用性实际归零。
反过来，主动丢掉 10% 的请求，剩下 90% 依然能正常、可预测地返回。被丢掉的那部分用户立刻收到明确失败，可以重试或走替代方案；而“全员变慢”时，所有人都在等一个可能永远不来的结果。快速失败好过集体卡死，这就是过载保护的核心判断。
丢谁，怎么丢
丢请求不是随便丢，通常按几个维度选：
- 按优先级：核心交易链路保住，推荐、埋点、导出这类可以牺牲。
- 按成本：特别贵、特别占资源的请求先拒，比如超长上下文、超大文件。
- 按客户端：某个调用方刷得太猛，就针对它丢。
- 随机丢：没有明显优先级差异时，按比例随机丢一部分，保证公平。
触发信号通常是自身的健康度：队列深度、尾延迟（p99）、并发数、内存水位。只看 CPU 往往来不及，因为排队已经开始，CPU 可能还没跑满。
和相邻概念的区别
| 概念 | 关注什么 | 典型动作 |
|---|---|---|
| 限流 Rate Limiting | 入口的速率与配额 | 超过配额直接拒 |
| 过载保护 Load Shedding | 自身是否已经扛不住 | 按优先级丢/降级部分请求 |
| 背压 Backpressure | 通知上游减速 | 让生产者少发一点 |
| 熔断 Circuit Breaking | 下游是否故障 | 暂停调用，快速失败 |
| 降级 Degradation | 能力不足时怎么凑合 | 返回简化结果而非拒绝 |
简单说：限流是门口的保安，按规则拦人；过载保护是店里快撑不住时的最后一闸；背压需要上游配合；熔断针对的是下游；降级是“给个简版”，过载保护是“这次不给了”。
对从业者的实际意义
在 AI 服务里，这件事格外重要。一次推理请求的成本差异可能是几十倍，GPU 前排着队，一旦过载，延迟会一起爆掉，而用户对首字延迟极其敏感。所以在设计之初就要想清楚：真到那一刻，我丢哪类请求、返回什么错误码、客户端该等多还是立刻重试。
工程上有几个常见做法：失败响应里带上建议的重试等待时间；客户端重试要加退避和抖动，别让重试变成第二波洪峰；把过载保护开关和阈值提前演练，而不是出事时临时拍脑袋。各家框架和云服务的具体触发参数、错误码约定不尽相同，以官方文档为准。
对普通人来说，这也解释了一个体验差异：某个应用在高峰时偶尔弹“稍后再试”，往往比一直转圈、最后全部失败要健康得多。它是在明确告诉你，它知道自己扛不住了。