容量规划与过载恢复

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

清理积压靠净余量

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

$$\dot{Q}=\lambda -C;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}(p\ne 1).$$

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

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

实验最多三次尝试。默认无重试，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 积压处理文章提供隔离和积压恢复的工程经验；Google SRE强调请求成本与资源信号。这里没有一个适用于所有系统的 70% 或 80% 利用率阈值。

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

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

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

自检

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

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