处理过载：与其硬撑到全盘崩掉，不如体面地拒绝一部分

一句话

过载的关键从来不是"扛不扛得住"，而是扛不住的那一刻会发生什么。本章的主张有点反直觉：一个健康的服务必须有能力主动拒绝一部分请求——因为无差别地全盘接收，结局不是"每个人都慢一点"，而是有效吞吐（goodput）塌到接近零。围绕这一点，它给出四个可分别落地的动作：容量别用 QPS 度量、用资源度量；服务端要能降级和脱载；请求要预先分重要性；客户端要自适应节流，并给重试上三道闸。

Glossary · 术语表

坐标

本章出自 SRE 书 Part III「实践」，作者 Alejandro Forero Cuervo。它紧接前面两章负载均衡——那两章讲怎么把负载摊匀以避免过载，本章讲摊匀之后仍然过载了怎么办；下启第 22 章「应对级联失效」：本章是单个服务的自保，下一章是自保失败之后整片系统的塌方。对应现实里的每一次秒杀、每一次热点事件、每一次下游变慢引发的雪崩。

这章要解决什么

先说一句反直觉的：服务真正的危险区间不在"慢"，而在慢之后那几十秒。

看看不设防时会发生什么。一个额定约 10k QPS 的服务被推到 15k：请求先排队，队一长，响应时间从 50 ms 涨到几秒；在途请求堆在内存里，GC 压力上升、又反过来吃掉 CPU；客户端设了 1 秒超时，等不到就重试——原本 15k 的真实需求，变成 30k、45k 的到达率。而重试打进来时，队列里那些早已超时、没人再等的请求还在被认真处理。到这一步，CPU 打满，算力全花在没人要的结果上，goodput 掉到接近 0。

这不是"性能不够"，是结构性崩塌：负载开始自己喂自己。所以本章要解决的是——当负载超过容量，怎么让产出停在容量线上，而不是掉下悬崖。它把这件事拆成两半：服务端要能"主动少干"，客户端要肯"主动少发"。两边缺一不可，因为被拒的请求如果立刻原样打回来，服务端还是得花 CPU 去拒绝它。

核心内容，讲透

先扔掉 QPS：容量该用资源来度量

最常见的容量说法是"这个服务能扛 X QPS"。本章直接说这是个坏尺子：不同请求的成本可能差出一两个数量级——一次按主键查 3 条记录的读，和一次要扫 500 个分片的聚合，都算"1 个 query"，吃掉的算力完全不是一回事；而且流量组成会随功能上线、客户结构变化而漂移，昨天量出来的上限今天就不作数了。

Google 的做法是直接用资源消耗定容量，绝大多数场景下就盯 CPU。两个理由：一是在带垃圾回收（GC）的运行时里，内存压力会自然翻译成 CPU 消耗（内存紧张 → GC 更频繁 → 吃掉更多 CPU），盯住 CPU 就顺带盯住了内存；二是其余资源可以按比例配足，让它们几乎不可能先于 CPU 耗尽。CPU 还有个关键性质——它是可压缩资源，不够时请求只是变慢，不会像内存那样一到上限就把进程打死，这就给脱载机制留出了反应的时间窗口。

具体信号用的是执行器负载均值（executor load average）：进程里活跃线程数的指数衰减平均值，与可用 CPU 数一比，就得到一个连续的"我现在有多满"的读数。

优雅降级与脱载：两种"少干点活"

过载时服务端有两条路，性质完全不同。优雅降级是把答案做便宜：搜索只查内存里的一小部分索引而不是完整的磁盘索引、排序换成更简单的算法、个性化推荐退回静态热榜。请求仍然被服务了，只是质量降了一档。负载脱落则是干脆不服务：直接返回错误（HTTP 里通常是 503），把资源留给还能好好服务的那部分请求。

书里对降级给了一条相当克制的警告，值得单独记住：降级路径平时几乎不被执行，所以它极可能已经是坏的。真到过载那天你切过去，才发现那段代码早就跟主路径脱了节、甚至根本跑不通。对策是：模式尽量少、逻辑尽量简单，并且定期真的走一遍。

每客户配额与客户端自适应节流

一个共享服务的容量要分给很多客户，所以先有每客户配额——按资源速率（比如每秒能用多少 CPU 秒）而不是按 QPS 来分。配额之和通常故意超过总容量，赌的是大家不会同时用满；一旦真的同时用满，超配额的客户先被拒。

但这里有个绕不过去的问题：拒绝不是免费的。一个疯狂重试的客户，能把服务端的 CPU 全花在"生成拒绝响应"上。所以本章最漂亮的一招落在客户端：自适应节流（adaptive throttling）。每个客户端任务自己记两个数（最近 2 分钟的滑动窗口）：requests（应用层发起了多少请求）与 accepts（后端真正接受了多少）。正常时两者贴得很近；后端一开始拒绝，accepts 就落在后面。客户端据此在本地按概率丢掉一部分请求，压根不发出去：

白话讲：发出去的比被接受的多出太多时，就按超出的比例先自己拒掉一部分。K 通常取 2，意思是"允许我发的量是后端接受量的两倍"——K 越小越激进、越早开始自我压制，K 越大越宽松；分母加 1 只是为了避免除零。

两个设计细节才是精髓。一是这个概率永远到不了 1，客户端始终会漏一点请求出去——这是它探测"后端恢复没有"的唯一途径，accepts 一回升，节流就自动松开，不需要任何人去手工解除。二是被本地拒掉的请求照样计入 requests，所以客户端不会自欺欺人地以为压力已经消失。

重要性（criticality）：先砍哪一刀是预先定好的

脱载要丢一部分请求，那丢谁？本章的答案是：别在过载那一刻现想，提前给请求分级。Google 的 RPC 系统里有四个等级，从高到低：

• CRITICAL_PLUS：出问题会造成严重的、用户可见的影响。
• CRITICAL：生产任务发出请求的默认级别，会有用户可见影响但没那么严重。服务的容量规划要能扛住这两级的总量。
• SHEDDABLE_PLUS：可以接受部分不可用；批处理任务的默认级别，因为它们几分钟、几小时后重试都行。
• SHEDDABLE：可以接受经常性的部分不可用、偶尔完全不可用。

两个机制让它真正好用。第一，重要性沿调用链自动传播：一个服务收到 CRITICAL 的请求，它为完成这个请求而发出的下游请求默认也是 CRITICAL——不需要每一层各自去猜。第二，配额按重要性分别记账：同一个客户在 CRITICAL 上的配额和在 SHEDDABLE 上的配额是两本账，避免了"用低价值流量把高价值的额度吃光"。脱载时，任务永远从最低重要性往上砍。

重试：最容易把自己送走的那一步

过载时最危险的正反馈来自重试。本章讲了一个必须内化的算术：每层各重试 3 次、三层调用链叠起来，最底层收到的请求量就是 3³ = 27 倍——而它本来就是因为撑不住才失败的。你以为重试在提高成功率，实际上是在给一台已经着火的机器浇油。

三道闸把它压回去：

1. 每请求的尝试上限：同一个请求最多 3 次尝试，用完就把失败向上抛，别在本层无限磨。
2. 每客户端的重试预算：客户端持续统计"重试数 / 请求数"这个比值，只在低于 10% 时才允许重试。这条最狠也最有用——它把整个系统的请求量放大上限锁在约 1.1 倍，无论下游多惨，洪水都涨不起来。
3. 让"别重试"能往上传：后端因过载而拒绝时，返回的是一个明确的"过载，别重试"标记，而不是普通错误。上游看到它就不再重试、直接把失败继续上抛。这条正是用来消掉那个 27 倍的乘法——否则每一层都会独立地"好心"再试一遍。

还有一条判断规则：过载是局部的还是普遍的，决定了该不该换个地方重试。如果只有少数任务过载，立刻换一个健康任务重试是对的；如果整个数据中心大面积过载，重试只是把问题搬个位置，正确做法是让错误一路上抛给调用方，让它去决定降级还是放弃。

别忘了连接本身也是负载

最后一个容易漏掉的点：光是维持连接就要花钱。健康检查、保活、连接的建立与拆除，在客户端数量极大时可能压过真正的请求处理。典型场景是一个批处理作业起了成千上万个 worker，每个都去连同一个后端——请求量并不大，连接开销却先把后端拖垮了。对策是让这类海量客户端经由一小组代理任务汇聚连接，把面向后端的连接数从"worker 数"降到"代理数"。

关键权衡与选型

表 1 · 用什么信号判断「我过载了」

表 2 · 过载时服务端的四种反应

表 3 · 重试的三道闸各挡住什么

为什么重要 / 落到真实系统

这一章在十年后仍是限流、熔断、降级这类设计的通用底本，是因为它把过载处理拆成了四个可以分别落地的动作：度量什么、服务端怎么少干、请求怎么分级、客户端怎么少发。今天你在 Envoy / Istio 里看到的自适应并发过滤器，在 Hystrix / Sentinel 里看到的熔断与降级，在各家 SDK 里看到的重试 token bucket，本质上都是这套东西的再实现。面试里"服务过载了怎么办"的标准好答案，也正是这四层——而不是"加机器"。

易错点与争议

• 把脱载当成免费的：拒绝一个请求也要解析、鉴权、记日志。若单次拒绝的成本逼近处理成本，脱载救不了你——解法是把拒绝往外推（负载均衡器、边缘代理），越早拒越便宜。
• CPU 不是万能信号：对 IO 密集、瓶颈在下游数据库的服务，CPU 闲着而系统早已过载。Netflix 2024 年那篇改用延迟 / 并发，正是为了这个。
• 客户端节流依赖客户端听话：自适应节流是 Google 内部同构环境的产物——所有服务共用一套 RPC 框架。面向不受控的第三方客户端（公开 API、用户手机上的旧版 App），你必须在服务端强制，不能指望对方自觉。
• 重试预算不共享就白设：每个客户端各自守住 10%，但调用链上每一层都是"另一个客户端"，放大依然会相乘——这正是第三道闸存在的理由，别只做前两道。
• 降级模式做太多：每多一个模式，就多一条几乎不被执行的代码路径。书里的态度很明确：尽量少、尽量简单，并且定期演练。
• 「自动扩容能解决过载」：扩容是分钟级的，尖峰是秒级的；新实例还要预热、拉配置、填缓存，可能恰在最糟的时刻加重下游压力。扩容与脱载互补，不是替代。
• 时代局限：本章成书于 2016 年，写的是 Google 内部同构 RPC 世界的做法。此后 service mesh 把这些能力下沉到了 sidecar，"从延迟反推限额"的自适应并发控制（思路借自 TCP 拥塞控制）成了主流补充。本章的框架没过时，但"用 CPU 当信号 + 靠自家 RPC 框架传播重要性"这两条实现细节，在异构环境里需要替换。

要点