当前位置：首页 > news >正文

从健康码崩溃到秒杀系统：QPS、TPS、RT这些指标到底怎么用？

news 2026/5/28 21:50:33

从健康码崩溃到秒杀系统：QPS、TPS、RT这些指标到底怎么用？

去年双十一零点刚过，某电商平台的秒杀系统突然出现大面积卡顿。技术团队紧急扩容服务器后，系统反而彻底崩溃。事后复盘发现，问题出在团队盲目增加了线程池数量，导致数据库连接耗尽——这恰恰是只关注QPS数值却忽视RT和TPS联动的典型反例。

当我们在讨论系统性能时，QPS、TPS、RT这些指标就像汽车的转速表、时速表和油耗计。单独看某个数值毫无意义，关键是要理解它们之间的动态关系。本文将用三个真实场景，带你掌握这些指标的实战用法。

1. 指标的本质：不只是数字游戏

1.1 QPS的隐藏陷阱

某省健康码系统在全员核酸检测时崩溃，当时监控显示QPS仅为设计容量的60%。深入分析日志发现：

虚假QPS：健康状态查询接口实际由5个微服务组成调用链

真实情况：

# 表面QPS 前端请求 -> 网关层 : 2000 QPS # 实际下游调用 网关 -> 身份服务 : 2000 QPS 网关 -> 核酸服务 : 2000 QPS 网关 -> 行程服务 : 2000 QPS

这揭示了一个关键认知：QPS需要区分入口调用和内部调用。我们常用压测工具得出的QPS值，往往只是系统最外层的"表面温度"。

1.2 TPS的业务权重

某金融系统在促销活动时出现异常：TPS达标但实际成交率暴跌。根本原因是：

指标类型	正常情况	异常情况
订单创建TPS	1500	1500
风控检查TPS	1500	300
支付回调TPS	1500	1200

提示：真正的系统容量取决于最慢子系统的TPS，就像木桶的短板效应

1.3 RT的百分位思维

某视频平台发现，虽然平均RT保持在200ms，但用户投诉仍然不断。通过P99指标分析发现：

平均RT：200ms
P90 RT：350ms
P99 RT：2100ms

关键结论：系统体验由最慢的那1%请求决定。我们建议采用如下监控策略：

设置P50 RT基线告警
P90 RT超过基线2倍时触发预警
P99 RT持续超标时立即扩容

2. 容量规划实战：从公式到落地

2.1 电商秒杀场景拆解

假设准备618大促，预期峰值流量为10万QPS。传统计算公式：

所需机器数 = 总QPS / 单机QPS

但实际需要考虑以下因素：

流量突增系数（通常取2-3倍）
冗余系数（建议30%）
部署单元化（避免单机房故障）

更科学的计算公式：

def calculate_machine(total_qps, single_qps): burst_factor = 2.5 # 流量突增系数 redundancy = 1.3 # 冗余系数 return math.ceil((total_qps * burst_factor) / single_qps * redundancy)

2.2 数据库连接池配置

某社交平台在明星官宣时崩溃，根源是数据库连接池配置不当：

参数	初始值	优化值	原理说明
maxActive	200	800	匹配应用线程池大小
maxWait	5000ms	300ms	快速失败避免雪崩
minIdle	10	50	预热连接减少RT波动

注意：连接数不是越大越好，需匹配后端数据库处理能力

3. 性能瓶颈定位：指标联动的艺术

3.1 黄金三角关系

通过某物流系统真实案例，我们发现QPS、TPS、RT存在动态平衡：

健康状态：
- QPS ↑ → TPS ↑ (线性增长)
- RT 保持稳定
临界状态：
- QPS ↑ → TPS →
- RT 开始波动
崩溃前兆：
- QPS ↑ → TPS ↓
- RT 急剧上升

3.2 线程池优化实战

某支付网关通过调整线程池参数提升性能：

// 错误配置 ThreadPoolExecutor( corePoolSize = 100, maxPoolSize = 500, queueCapacity = Integer.MAX_VALUE ) // 优化配置 ThreadPoolExecutor( corePoolSize = 50, maxPoolSize = 200, queueCapacity = 1000, rejectionPolicy = CallerRunsPolicy() )

优化效果对比：