QPS、TPS、RT 和并发数有什么区别？如何估算并验证系统容量？

知识点详解：怎样从流量数字走到容量判断？

同一个数字，必须先讲清统计口径

假设登录页面一次操作会调用三个接口。一个用户操作，不等于一个 HTTP 请求；一个数据库事务，也不等于一次完整登录。

因此，TPS 中的“事务”要先定义。压测报告写一千 TPS，如果不知道事务包含什么，就无法和另外一份一千 QPS 的报告直接比较。

RT 也需要边界：是服务端处理时间、网关到服务的时间，还是用户点击后到页面可用的时间？不同边界包含的网络、排队和渲染开销不同。

并发数为什么会随响应时间变大？

假设系统稳定地每秒接收一千个请求，平均每个请求停留 0.1 秒，那么平均同时在场的大约是一百个请求。

如果平均停留时间变成一秒，同样到达速度下，就可能有约一千个请求同时在场。它们未必都在 CPU 上运行，其中很多可能在等数据库、网络或连接池。

这就是平均在途数量、吞吐率和平均停留时间之间的关系。要使用它，系统应相对稳定，进入和离开数量长期相符，三个指标要采用同一统计边界。

不能拿 p99 延迟代替平均时间，直接声称得到了“p99 并发”；也不能在队列持续增长的过载阶段，把这个公式当成可靠上限。

图：同样流量，变慢就会多积压。

压测为什么要看流量模型？

固定并发用户模型中，一个虚拟用户通常等前一个请求结束再发下一个。服务变慢后，每个用户发送的频率可能下降，于是压力会跟着下降。

到达率模型则尝试按给定速率启动请求，更容易观察“外部流量不停到来”的情况。两种模型对应不同问题，不存在统一的更好模型，见 k6 的开放与封闭模型说明。

要验证突发流量，不能只靠一个会随响应变慢而自动降压的模型。同时也要检查压测机自己是否已经成为瓶颈。

图：固定并发与固定到达率，压力不同。

怎样定义“容量够了”？

不是把机器压到完全不报错，就记录最高 QPS。应先确定可接受的延迟、错误率和持续时间，再测试真实请求比例、数据规模及冷热状态。

随着负载增加，观察哪里先出现问题：CPU 饱和、连接池等待、数据库锁竞争，还是下游限额。特别要看尾延迟和排队长度，平均延迟可能掩盖少量严重超时。

最后还要考虑一台实例故障、扩容尚未生效等情况。Google SRE 的 过载处理 也强调保护系统，而不是无限接收超过能力的工作。

面试官继续追问

一台机器能跑一千 QPS，十台就是一万吗？

不一定。数据库、缓存、网络和外部服务可能共享瓶颈；流量分配也不一定均匀。横向扩容后的容量仍需要验证。

线程池应该等于估算的并发数吗？

不能直接设置。估算包含等待中的请求，线程模型也可能是同步、异步或虚拟线程。需要看工作负载、连接池和下游承受能力。

平均 RT 很低，还需要看 p99 吗？

需要。少量长尾请求会影响用户体验、重试和资源占用。容量判断应同时包含尾延迟与错误率。

面试速记卡

• QPS/TPS：先统一请求和事务的统计口径。
• RT：说明从哪里开始、到哪里结束。
• 并发：在途请求不等于线程、连接或在线用户。
• 粗估：稳定系统中，平均在途数量约为吞吐率乘平均停留时间。
• 容量验证：真实负载、尾延迟、错误率、瓶颈和故障余量一起看。