GeoXMind

过载保护要在系统失速前拒绝部分工作

说明并发限制、队列边界、负载卸除、熔断和降级怎样阻断正反馈，并分析重试与容量转移造成的级联风险。

过载保护要在系统失速前拒绝部分工作

服务接近容量极限时，继续接受所有请求往往不会多完成工作。队列拉长使请求在开始处理前就已超时，调用方重试又增加负载，健康检查失败触发实例重启，剩余实例承担更多流量，局部过载便可能扩展为级联故障。

过载保护的目标不是让每个请求都成功，而是在资源有限时维持尽可能多的有效工作，并阻止失败形成正反馈。并发限制、负载卸除、熔断、降级和重试预算需要作为一套控制回路设计。

先找到容量边界和失速方式

容量不能只用平均 QPS 表示。请求成本可能相差数百倍，CPU、内存、连接、线程、下游配额和锁竞争也会先后成为瓶颈。团队需要在接近生产的环境中逐步和突发加压，观察吞吐、延迟、错误与资源之间的关系。

健康的过载曲线是在饱和后吞吐保持稳定，额外工作被快速拒绝；危险曲线则是在某点之后吞吐下降、延迟急升并引发崩溃。Google SRE 对级联故障的讨论强调，应测试到失败并继续观察恢复，而不只证明系统能承受目标流量。

容量测试还要包含依赖变慢、实例减少、缓存失效和发布切换。单个服务的稳定上限在依赖变化后可能完全不同。只有知道首先耗尽的资源和可恢复路径，准入信号才有依据。

队列与并发必须有上限

无界队列把拒绝推迟成超时，并占用内存和连接。队列上限应根据可接受等待时间、处理速率和请求期限设置。已不可能在期限内完成的请求应尽早退出，避免消耗下游资源。

并发限制比单纯每秒限流更接近实际占用。处理变慢时，同样 QPS 会累积更多并发；基于进行中请求、队列长度或自适应延迟的限制可以更早反映饱和。限制本身也要设置最小容量和变化速度，避免因短暂抖动把服务压到无法恢复。

不同工作价值不同时，应定义优先级和公平策略。交互请求、后台刷新和批处理不能争用同一无差别队列。保留关键控制流量的容量，能避免故障期间连管理与恢复请求也进不去。

负载卸除要快速、便宜并可识别

负载卸除是在过载前后拒绝部分请求，使剩余请求可以完成。拒绝路径必须比正常处理便宜，不能先执行昂贵解析或数据库查询再返回错误。HTTP 服务常使用清晰的不可用响应和重试提示，但具体语义要与协议及客户端约定一致。

选择丢弃谁不能完全随机。可以按请求优先级、期限、租户配额或计算成本决策，同时防止高流量租户占满公共容量。降级则是在保持响应的同时减少工作，例如返回较旧缓存、缩小结果或关闭非关键扩展。

降级结果必须可识别，避免调用方把低质量结果当成完整结果写入永久数据。触发次数、被拒绝工作量和用户影响需要监测，过载模式也要定期演练。很少执行的备用路径最容易在真正故障时失效。

熔断器隔离持续失败的依赖

当依赖连续超时或错误时，熔断器暂时阻止新调用，使调用方快速失败并给依赖恢复空间。典型状态包括关闭、打开和半开：正常时放行，超过条件后打开，等待一段时间再用少量探测判断是否恢复。

触发条件不能只数连续错误。低流量服务的少量失败和高流量服务的一小部分失败含义不同，需要最小样本、时间窗口、错误类型和延迟阈值。业务拒绝、客户端参数错误不应都算作依赖故障。

半开探测要限制并发，否则大量实例会同时探测刚恢复的依赖。加入抖动、共享容量信号或逐步放量能降低同步冲击。熔断器也不能替代端到端期限和资源隔离；它只在已观察到故障后减少继续调用。

重试可能抵消所有保护

调用链每层都重试，会指数放大最下游流量。请求已经在服务端执行成功但响应丢失时，非幂等重试还可能产生重复副作用。应明确由哪一层重试，设置总期限、次数预算、指数退避和随机抖动，并只对可恢复错误重试。

服务端卸除后，客户端若立即重试，拒绝流量会原样返回。客户端需要遵守退避和服务器提示，并在本地达到预算后让失败向上传递。Google SRE 将负载卸除、优雅降级和客户端节流放在同一过载问题中，原因就在于局部策略会通过反馈相互影响。

流量转移同样可能扩散故障。一个区域过载后把全部请求切到另一区域，可能让健康区域也跨过容量边界。故障转移前要计算剩余余量，必要时保留部分拒绝，而不是追求表面上的全接收。

保护策略需要可验证的运行契约

每个服务应说明最大并发、队列边界、优先级、拒绝语义、降级内容、熔断条件和重试责任。调用方必须知道哪些错误可重试、响应是否完整、幂等键如何使用。没有跨团队契约时，一方的保护会成为另一方的异常放大器。

监测至少包括接受、完成、拒绝、排队、进行中、超时和重试量，并按原因与优先级切分。只看成功率会把主动拒绝和内部崩溃混为一谈，也看不到保护是否让有效吞吐保持稳定。

阈值应来自容量试验和故障演练，并可逐步调整和快速回退。复杂自适应控制在异常时也可能振荡，简单、可理解的上限往往更可靠。任何自动策略都要有观测、关闭和人工接管路径。

过载保护成功的标志不是零错误，而是在超出容量时错误有界、关键工作仍能完成、系统能够自行回到正常状态。主动舍弃部分工作，常常是保住整体可用性的必要选择。

资料依据