利用率与排队的关系
排队系统里利用率与等待时间不是线性关系：利用率越接近 100%，等待时间增长越陡，因为队列长度取决于“到达速率与服务速率的差”而不是比值本身。这条规律决定了容量规划的现实做法——给关键资源留出裕量，把利用率控制在拐点以下，而不是压榨到最后一点空闲。
基本信息
| 核心量 | 到达速率 λ、服务速率 μ、利用率 ρ=λ/μ、平均队列长度与等待时间 |
|---|---|
| 经典结论 | M/M/1 模型下平均等待约正比于 ρ/(1-ρ) |
| 实践含义 | ρ 从 80% 提到 90%，等待时间大致从 4 倍系数涨到 9 倍系数 |
| 适用范围 | 结论随到达分布变化，但“越饱和越敏感”这个方向不变 |
典型使用场景
- 容量规划：用排队推导反算需要多少实例才能把 P99 压到目标内
- 扩容决策：判断当前是容量不足还是共享点争用，避免盲目加机器
- 限流参数：按目标队列等待时长反推入口限流阈值
- 超时与重试预算：用预期排队时间给超时留出足够空间，减少无效重试
- 存储与网络规划：IO 队列深度与队列等待时间同样遵循这个规律
直觉
直觉
M/M/1 近似：平均等待 ∝ ρ / (1 - ρ)
ρ=50% → 等待系数 1
ρ=80% → 等待系数 4
ρ=90% → 等待系数 9
ρ 趋近 100% → 等待时间发散
结论：把资源跑到高利用率，等于把延迟押在很小的余量上利用率与容量动作
| 资源利用率 | 延迟特征 | 建议动作 |
|---|---|---|
| 低于 50% | 等待影响很小，余量充足 | 可作为低峰期的常态水位，适合安排批处理与压测 |
| 60%~70% | 开始出现可观测的等待 | 作为日常预警水位，关注趋势斜率 |
| 70%~80% | 等待对流量波动敏感，峰谷差异被放大 | 扩容或分流，避免峰值突破 80% |
| 80% 以上 | 等待非线性上升，抖动即放大会出现超时 | 立即扩容或降级，视为容量告警 |
落地做法
- 把利用率看板与延迟分位联动展示，观察拐点与相关性，而不是分开看两个数
- 对关键资源设利用率预警水位（常见 70%~80%），并按峰时段而非全天平均口径评估
- 按峰时段口径评估饱和度：全天平均利用率达标经常掩盖了峰段的排队爆发
- 扩容后复测扩展斜率，用实测曲线而不是实例数外推容量
不同到达分布下系数会不同（突发到达比泊松到达更敏感），但共同点是：饱和度越高，等待时间对流量波动越敏感，同一套容量在高峰与低谷表现差异很大。
用平均利用率做扩容依据是常见误判来源：平均值达标只能说明均值，无法代表峰时段的排队与超时，评估口径要落到分位与峰段。