本篇要回答的问题：第三类故障——由终端用户请求导致的过载，它的成因与后果是什么？雪崩效应如何形成？又该如何监控过载、并从服务端 + 客户端两侧把损失降到最低？
承接前两讲（51 故障域、52 根因分析）。本讲处理三大故障来源的最后一类——终端用户请求引发的"过载"。本质上这是一个容量规划问题：活跃用户超过资源承载能力，导致资源耗尽。
过载的成因
| 成因 | 说明 |
|---|---|
| 用户增长太快 | 资源规划预期没跟上，储备不足 |
| 部分资源故障下线 | 双机房容灾需按 2 倍容量规划，否则一个机房挂掉就不足 |
| 关键资源负载能力变低 | 如数据库越来越大，到临界点后延时变长、并发变低 |
| 重试导致反应过激 | 见下——请求放大 |
关键判断：重试会成倍放大请求。一个 API 失败重试 2 次=放大 3 倍；客户端+服务端都重试=9 倍；若内部 API 也重试，对内部 API 可放大至 9～81 倍。
过载的后果：连锁反应与雪崩
过载表现为"资源耗尽"（如 CPU 持续逼近 100%→请求变慢→处理中请求数上升→内存/socket/后端资源连锁消耗）。
关键洞见：过载通常有连锁反应——某类资源耗尽会拖垮其他资源，一个服务过载会冒出一串看似都像根因的过载现象，使定位更难。
雪崩效应是如何形成的
| 步骤 | 数值示例 |
|---|---|
| 实例正常承受 QPS | 10000 |
| 自然请求数 | 11000 → 1000 个失败 |
| 失败重试放大 9 倍 | QPS 升到 20000（2 倍正常负荷） |
| 实例被压垮 | 请求转移到互备实例 → 互备也被压垮 → 服务完全挂掉 |
过载的监控：别只盯 QPS
| 方式 | 评价 |
|---|---|
| 给 QPS 设阈值告警 | 看似不错，但维护成本高：新版本可能突然让单请求资源消耗大变，阈值早晚失效 |
| 基于关键资源（CPU/内存）量容量 | 更稳定可靠；多数情况下简单地用 CPU 使用量作容量指标，效果就已非常好 |
应对策略：服务端 + 客户端两侧
大思路有二：降低过载发生概率；即便发生也杜绝雪崩、把损失降到最低。手段可由服务端做，也可由客户端做。
服务端能做什么
| 手段 | 要点 |
|---|---|
| 过载时主动拒绝请求 | 进入过载即尽早把请求标记失败，保护自己；可全局粗粒度，也可按用户配额细粒度（理想是只对"异常"客户返错，不波及其他人）；基于资源比基于 QPS 稳 |
| 让 LB 也做过载保护 | 双保险，业务服务器漏做时 LB 兜底 |
| 容量规划 | 降低连锁反应概率，需配合性能测试确定失败负载点；只能减少、不能完全避免连锁反应 |
| 服务优雅降级 | 按请求类型与重要性降级（优于无脑拒绝）；但不应经常触发（否则=容量规划失误），且需定期压测触发以保证降级代码分支可用 |
关键判断：不太触发的代码分支有可能是不能正常工作的——优雅降级的代码要靠定期压测来"保鲜"。
客户端能做什么
| 话题 | 做法 |
|---|---|
| 重试 | 限次（如 2 次）；用随机化、指数型递增的重试周期（3s→6s→12s）；设全局重试预算（如每进程每分钟 60 次），预算耗尽直接标失败不发送 |
| 重要性级别（criticality） | 标 1～4：可丢弃 / 可延后 / 重要 / 非常重要；过载时按序优先放弃 |
| 延迟与截止时间（deadline） | 给 API 设小而合理的超时是降雪崩的有效手段；多阶段请求每阶段前检查 deadline，避免做无用功 |
| 客户端节流（自适应节流） | 天然优势：本地拒绝不浪费服务端资源 |
自适应节流算法
客户端记录过去两分钟的 requests（应用层发出总数） 与 accepts（被服务端接受数）：常规下二者相等；后端开始拒绝时 accepts 变小。客户端可发到 requests = K × accepts，超过则本地按概率拒绝新请求。
关键洞见：本地拒绝的请求虽没到后端，但会让 requests 持续超过 accepts，从而提高本地丢弃概率——这恰是算法重点。它仅靠本地信息决策、实现简单、不增依赖、不影响延迟，超大过载下后端仍能保 ~50% 处理率。
| K 值 | 服务端处理率 | 适用 |
|---|---|---|
| K=2（默认） | 50% | 通用 |
| K=1.1 | 90%（激进） | 处理请求与拒绝请求资源消耗相差无几的系统 |
总结
过载=活跃用户超过资源承载、某类资源耗尽。系统过载时总有东西要被牺牲——越过临界点后，服务部分用户错误/低质量结果，好过尝试继续服务所有请求。理解临界点与越界后的行为模式，是避免雪崩的 SRE 必备能力。讽刺的是，重试、负载转移、自动杀不健康实例、加缓存等优化正常态性能的手段，本身也是过载与雪崩的成因。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 过载 | 活跃用户超过资源承载，资源耗尽 |
| 请求放大 | 多层重试把请求放大数倍至数十倍 |
| 雪崩效应 | 正反馈循环下短时间压垮实例并扩散至互备 |
| 容量规划 | 过载本质是容量问题，需配合性能测试 |
| 优雅降级 | 按重要性丢请求；需压测保鲜代码分支 |
| 自适应节流 | 客户端用 requests/accepts 本地按概率拒绝 |
| criticality | 请求重要性 1～4 级，过载时按序放弃 |
一句话速记
过载本质是容量问题，重试放大+正反馈=雪崩；监控容量用 CPU 比用 QPS 稳，服务端主动拒绝/优雅降级、客户端限次重试/自适应节流（K=2 保 50% 处理率）双管齐下，越过临界点就该主动牺牲部分请求。
几条值得记住的判断
- 重试是雪崩的隐形推手，可把请求放大到 9～81 倍。
- 用 CPU 等资源量容量比用 QPS 阈值更稳。
- 优雅降级不该常触发，且要定期压测保鲜代码分支。
- 客户端自适应节流仅靠本地信息、不浪费服务端资源，是优雅的兜底。
思考题
文中说"重试、负载转移、加缓存等优化正常态的手段，本身也是过载与雪崩的成因"。回到你的系统：你为提升可用性加的哪一项机制（自动重试？自动故障转移？），在极端流量下反而可能加速雪崩？给它配上限次/退避/全局预算了吗？
