QPS、并发数与响应时间的容量估算方法

容量规划最怕拍脑袋。只说“准备十台机器”没有意义，必须把用户量转换为请求量，再把请求量转换为 CPU、连接、缓存和磁盘的预算。

先区分四个指标

• QPS：每秒完成的请求数，适合描述接口吞吐。
• TPS：每秒完成的事务数，通常关注提交成功的业务事务。
• 并发数：同一时间处于处理中的请求数。
• P95/P99：尾部响应时间，决定用户是否感受到卡顿。

平均响应时间很好看，并不能掩盖少量请求被锁、慢 SQL 或 GC 拖到几秒的事实。容量目标至少要写成“峰值 3000 QPS，P99 小于 200ms，错误率低于 0.1%”。

用 Little 定律连接指标

Little 定律可以写成：

并发数 = 吞吐量 × 平均响应时间

如果接口稳定在 2000 QPS，平均响应时间 100ms，那么应用层平均并发约为 200。若 P99 变成 800ms，连接、协程和线程需求会同时放大，数据库连接池也可能先被耗尽。

从业务事件反推峰值

假设一次营销活动有 50 万用户，10% 在 5 分钟内打开页面，平均每人触发 8 次 API 请求：

总请求 = 500000 × 10% × 8 = 400000
平均 QPS = 400000 / 300 ≈ 1333
峰值 QPS = 平均 QPS × 2.5 ≈ 3333

2.5 不是固定答案，需要通过历史活动、埋点和压测修正。没有历史数据时，应把峰值系数、缓存命中率和重试率作为显式假设。

画出分层容量表

组件	单实例安全容量	目标峰值	需要实例
API 服务	450 QPS	3333	8
Redis 分片	80000 ops/s	120000	2 个分片
主库写入	1500 TPS	900	1 主 + 1 备
消费者	250 条/s	1200	6

单实例安全容量应取压测曲线中 P99 和错误率都满足目标的点，再留出 30% 至 50% 余量。不能把 CPU 跑到 95% 的极限吞吐当成生产容量。

连接池是隐藏上限

应用实例数增加后，数据库总连接数会线性增加。8 个实例、每个连接池 50，意味着数据库可能面对 400 个连接。若主库只能稳定处理 180 个活跃连接，就算应用还有 CPU，整体仍会排队。

更稳妥的做法是：

1. 先确定数据库可接受的总连接数；
2. 按实例数和读写比例分配连接池；
3. 监控等待连接时间，而不只监控连接数；
4. 把超时请求从连接池中及时释放。

压测验收

压测报告至少保留并发曲线、吞吐曲线、P50/P95/P99、错误分类、CPU、内存、GC、连接池、缓存命中率和数据库锁等待。用阶梯加压找到拐点，再用峰值流量持续 30 分钟验证稳定性。

容量数字只有在压测环境、数据量、缓存命中率和依赖版本都写清楚时，才具备可复用价值。