【架构】如何预估一个系统的QPS？

预估一个系统的 QPS（Queries Per Second，每秒查询数）是系统设计、容量规划和性能评估中的关键步骤。准确的 QPS 预估有助于合理配置服务器资源、避免系统过载或资源浪费。以下是预估系统 QPS 的常用方法和步骤：

一、什么是 QPS？

QPS（Queries Per Second）表示系统 每秒钟能够处理的请求数量，是衡量系统吞吐能力的重要指标。有时也会使用 TPS（Transactions Per Second，每秒事务数），区别在于 TPS 更强调“事务”的完整性，而 QPS 更泛指请求。

二、QPS 预估的主要方法

方法一：基于业务场景和用户行为预估

• 这是最常见也是最基础的预估方式，适用于产品初期或新功能上线前，没有历史数据可参考的情况。

步骤：

1、明确核心业务请求

• 确定哪些接口/操作是系统的主要负载来源。比如：用户登录、商品查询、下单等。

2、预估用户量与访问频率

• DAU（日活跃用户数） 或 MAU（月活跃用户数）：根据产品目标或市场调研获得。
• 每个用户的请求频率：比如平均每个用户每天发起多少次请求。

3、计算每日总请求数

每日总 Q=DAU×每个用户日均请求次数

4、换算为 QPS

QPS=每日总Q/86400

（一天有 86400 秒）

如果流量有高峰低谷，可以进一步按 峰值时段 来计算，比如只计算白天 9:00-22:00 的请求量，再除以对应秒数。

举例：

假设：

• 日活用户 DAU = 100万
• 每个用户平均每天发送 10 次请求
• 则每日总请求数 = 1,000,000 × 10 = 10,000,000 次
• 平均 QPS = 10,000,000 / 86400 ≈ 115.7 QPS

如果考虑 高峰期（如只占一天中的 20% 时间，即约 17280 秒）集中了 50% 的请求，则：

• 高峰期请求量 ≈ 5,000,000 次
• 高峰 QPS ≈ 5,000,000 / 17280 ≈ 290 QPS

所以，系统设计时一般要以 峰值 QPS 为目标进行容量规划。

方法二：基于已有业务数据推算

如果系统已经上线并且有访问日志或监控数据，可以通过分析历史数据来预估或验证 QPS。

步骤：

1、收集历史访问数据

• 从 Nginx/Apache 日志、API Gateway、应用日志、Prometheus、SkyWalking、ELK 等获取。
• 统计单位时间内的请求数（如每分钟、每小时请求量）。

2、分析请求分布

• 查看 一天内 QPS 的变化曲线，找出 峰值 QPS 和 平均值。
• 重点关注业务高峰时段，比如促销、节假日、上午/下午上班时间等。

3、推算未来规模

• 如果业务量会增长（比如用户数翻倍），按照比例推算未来的 QPS。
• 例如：当前日均 QPS 是 1000，预计用户数增长 3 倍，则目标 QPS 可能为 3000。

方法三：基于行业经验和类比

对于某些典型业务场景，可以参考业界标准或类似产品的 QPS 数据做类比估算。

注意：这些只是非常粗略的参考，实际需结合并发用户数、请求复杂度、响应时间等综合评估。

三、影响 QPS 的关键因素

在预估 QPS 之后，还需要了解哪些因素会影响系统实际能承载的 QPS，包括：

1、请求的复杂度

• 简单查询（如获取缓存数据） vs 复杂业务逻辑（如订单创建+库存扣减+通知）

2、后端服务性能

• 数据库查询速度、缓存命中率、外部接口延迟等

3、并发连接与线程模型

• Web 服务器（如 Nginx、Tomcat）的并发处理能力

4、系统架构

• 是否有负载均衡、服务拆分、异步处理、消息队列等优化手段

5、响应时间（RT）

• QPS 与响应时间关系密切，公式为：

QPS≈1000/RT（毫秒）

例如，若平均响应时间为 100ms，则单机理论最大 QPS ≈ 10；若 RT 为 10ms，则 QPS ≈ 100。

四、QPS 与并发数、响应时间的关系

三者之间有如下近似关系（Little’s Law）：

QPS=并发数/平均响应时间(秒) 

或者：

并发数=QPS×平均响应时间(秒) 

举例：

• 如果系统 QPS 为 1000，平均响应时间为 100 毫秒（0.1秒）
• 则并发连接数 ≈ 1000 × 0.1 = 100

这意味着系统需要同时处理约 100 个请求才能维持 1000 QPS 的吞吐量。

五、工具辅助估算与压测

1、压力测试工具

• 使用 JMeter、wrk、Locust、ab (Apache Benchmark) 等对系统进行压测，得出实际 QPS 上限。
• 压测是验证 QPS 预估是否合理的最直接方式。

2、监控与数据分析

• 通过 APM 工具（如 SkyWalking、Pinpoint、Prometheus + Grafana）实时观测 QPS、RT、错误率等。

六、总结：如何科学预估 QPS？

附加建议：

• 在系统设计初期就进行 容量规划 和 QPS 预估，避免上线后出现性能瓶颈。
• 建议按照 峰值 QPS 的 1.5 ~ 3 倍 进行容量冗余设计，视业务重要性而定。
• 引入 自动扩缩容机制（如 Kubernetes HPA） 和 缓存、异步、降级策略 提高系统弹性。

出处：https://blog.csdn.net/cookily_liangzai/article/details/153721904