排队模型能解释饱和，不能直接承诺 P99：先说清队列是否有限

到达率小于总服务率，于是接口延迟就能满足要求——这个推论少了一大步。平均负载只能描述部分压力，尾部还受服务时间分布、突发、批处理与调度影响。

先分清模型边界

经典无限等待队列中的稳态讨论，与有限队列满后拒绝请求的系统不同。有限队列的长度被容量限制，即使到达率超过服务能力也不会无限增长，但拒绝和等待会增加。把“不会长到无限大”当作服务健康标准，没有实际意义。

图中 λ、μ 的时间单位必须一致，1/μ 表示单个服务台的平均服务时间。并行服务台同质、到达与服务过程的独立性，都是需要验证的假设，不是接入网关天然具备的属性。

用有限队列看清守恒关系

下面是离散时间教学模拟。每个服务台每步完成一项工作，总在途容量为服务台数加等待位数；它不是 M/M/c 仿真，也没有生成 P99。

def simulate(arrivals, servers=2, waiting_slots=3):
    outstanding = accepted = completed = rejected = 0
    limit = servers + waiting_slots
    for incoming in arrivals:
        if type(incoming) is not int or incoming < 0:
            raise ValueError('nonnegative arrival counts required')
        done = min(servers, outstanding)
        completed += done
        outstanding -= done
        admitted = min(incoming, limit - outstanding)
        accepted += admitted
        rejected += incoming - admitted
        outstanding += admitted
        assert outstanding <= limit
    assert accepted == completed + outstanding
    assert sum(arrivals) == accepted + rejected
    return completed, outstanding, rejected

finished, pending, dropped = simulate([7] * 5)
assert (finished, pending, dropped) == (8, 5, 22)
print({'completed': finished, 'pending': pending, 'rejected': dropped})

队列一直有界，却拒绝了大量请求。若只看已完成请求的平均延迟，甚至可能漏掉那些根本没进系统的请求。这也是性能报告必须同时写拒绝率、超时和客户端放弃的原因。

让模型先接受真实分布的检验

采集时区分排队等待、服务处理与端到端耗时。按照请求类型查看分布，不用均值掩盖慢请求；把短时突发、长尾服务时间和失败重试纳入回放。若希望估算稳态概率，需要明确选择的队列模型与参数拟合方式。

Kubernetes 的 Kueue 准入跟踪文章说明了另一个容易混淆的层次：工作负载等待准入与 Pod 等待调度是不同阶段。测延迟时，应从正确的排队阶段开始计时。

本文只验证有限容量与计数守恒，没有运行随机排队模型、集群或请求压测。排队论适合帮助提出容量问题；要承诺 P99，还得回到可复现的流量与目标环境。