---
title: 容量规划与过载恢复
url: https://doc.liz6.com/theory/03-queueing-theory/11-capacity-and-overload-recovery
locale: zh
area: theory
tags:
- 排队论
- 基础理论
date: 2026-09-10
modified: 2026-09-10
description: 容量规划要同时回答三件事：日常时延能否达标，突发积压多久恢复，失败和重试会消耗多少额外工作。平均到达小于平均能力只是起点。
---

# 容量规划与过载恢复

容量规划要同时回答三件事：日常时延能否达标，突发积压多久恢复，失败和重试会消耗多少额外工作。平均到达小于平均能力只是起点。

## 清理积压靠净余量

确定性流体近似把任务当作可连续分割的工作。总处理能力为 $C$、到达工作率为 $\lambda$，积压非空时：

$$\dot Q=\lambda-C;\qquad Q=0\text{ 时 }\dot Q=\max(0,\lambda-C).$$

若已有积压 $Q_0$，后续固定到达 $\lambda<C$，清空时间为 $Q_0/(C-\lambda)$。$Q_0/C$ 仅适用于没有新工作到达的情况。这个清空时间是整个积压消失的时间，不等于某个队尾请求的 FCFS 等待；后来的请求通常排在它之后。

日常到达 60/s，能力 100/s，120/s 的突发持续 30 s，积压增加 600 个。恢复到日常流量后，净清理能力 40/s，还需 15 s。若能力只有 70/s，同一突发积压 1500 个，恢复余量只有 10/s，需要 150 s。

## 重试如何吃掉余量

最多尝试 $m$ 次、每次独立以固定概率 $p$ 失败，并且失败后才尝试下一次，则期望尝试数为：

$$E[A]=1+p+\cdots+p^{m-1}=\frac{1-p^m}{1-p}\quad(p\ne1).$$

无限尝试时才是 $1/(1-p)$。实际故障常有关联，且失败概率随负载变化；把 $p$ 当常数只是一个工作量近似。重试延迟会改变到达时间结构，不能把期望放大倍数当成真实逐时轨迹。

实验从 $Q(0)=0$ 开始，观察到240 s。积压以请求尝试的工作量计数；到达率已经包含期望的重试放大。

**容量规划与过载恢复 · 实验**

确定性流体近似，原始到达平时60/s、20–50 s为120/s；最多3次尝试，独立固定失败概率p，以1+p+p²近似即时工作放大。无退避延迟、无拒绝；并非真实重试过程或随机尾延迟模型。


实验最多三次尝试。默认无重试，20–50 s 突发后在 65 s 清空。保持能力 100/s，设 $p=0.3$，放大倍数 1.39，平时尝试率 83.4/s、突发积压 2004 个，突发结束后还需约 120.72 s。若 $p=0.5$，平时尝试率已到 105/s，系统没有正的恢复余量；图中应看到突发后仍增长。

## 把理论变成容量评审

1. 定义业务单位和成功条件。分别记录原始请求、尝试、接纳、成功、取消与过期，不把快速错误计成有效工作。
2. 测量瓶颈资源的服务需求，分类型记录均值、波动和尾部。CPU、连接、锁和远端配额可能限制不同阶段。
3. 在适用模型下估计稳态等待，再用开放/封闭且符合真实需求的压测检验目标。把模型偏差和测量不确定性纳入余量。
4. 重放突发、下游变慢、实例失效和重试场景，检查恢复时间及恢复期间的队列年龄、拒绝率和成功延迟。
5. 明确准入、租户隔离、过期任务、重试预算与扩容生效延迟。扩容增加有效能力之前，积压仍在产生。

[AWS 积压处理文章](https://d1.awsstatic.com/builderslibrary/pdfs/avoiding-insurmountable-queue-backlogs.pdf)提供隔离和积压恢复的工程经验；[Google SRE](https://sre.google/sre-book/handling-overload/)强调请求成本与资源信号。这里没有一个适用于所有系统的 70% 或 80% 利用率阈值。

## 与控制理论、消息系统连接

排队论描述负载和等待，控制理论描述根据观测如何调整动作。队列年龄、积压和资源使用率可以成为反馈；采样、平滑、扩容延迟和饱和又会影响恢复。前往[计算机系统中的控制](../02-control-theory/09-control-in-computing-systems.md)，把本篇的到达和服务模型放进动态决策过程。

消息系统还涉及持久化、重复、分区和重放，不能用一个 FIFO 图替代。接着读[消息语义](../../distributed-systems/07-messages-and-streams/01-message-semantics.md)与 [Kafka 架构](../../distributed-systems/07-messages-and-streams/02-kafka-architecture.md)。进阶方向包括更新过程、优先级队列、封闭网络均值分析、网络演算、重交通极限和状态相关服务；本系列不声称覆盖所有排队论。

## 自检

1. 已积压 10000 个，能力 1000/s，新流量 900/s，为何清空需要 100 s 而不是 10 s？

<details><summary>参考思路</summary>

每秒完成 1000 个同时又进入 900 个，净减少仅 100 个。10000/100=100 s；若新流量停止才是 10 s。若能力、到达或任务成本变化，需重新积分工作量。

</details>

2. 提高队列容量和增加消费者，哪种能保证解决过载？

<details><summary>参考思路</summary>

都不能无条件保证。加大队列只提供更多等待空间；增加消费者必须确实增加瓶颈的可用能力。若下游已饱和，更多并发可能加剧竞争。应先识别瓶颈与业务截止目标，再用故障和恢复实验验证方案。

</details>