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

从健康码崩溃到秒杀系统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达标但实际成交率暴跌。根本原因是指标类型正常情况异常情况订单创建TPS15001500风控检查TPS1500300支付回调TPS15001200提示真正的系统容量取决于最慢子系统的TPS就像木桶的短板效应1.3 RT的百分位思维某视频平台发现虽然平均RT保持在200ms但用户投诉仍然不断。通过P99指标分析发现平均RT200msP90 RT350msP99 RT2100ms关键结论系统体验由最慢的那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 数据库连接池配置某社交平台在明星官宣时崩溃根源是数据库连接池配置不当参数初始值优化值原理说明maxActive200800匹配应用线程池大小maxWait5000ms300ms快速失败避免雪崩minIdle1050预热连接减少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() )优化效果对比指标优化前优化后最大QPS1200015000P99 RT2.1s800ms错误率1.2%0.05%4. 应急预案设计指标驱动的弹性策略4.1 分级降级方案某票务系统采用三级降级策略一级降级QPS达到阈值80%关闭推荐算法简化页面静态资源二级降级RT超过500ms启用缓存数据关闭非核心校验三级降级错误率5%开启排队系统切换备用支付通道4.2 弹性扩缩容策略基于指标变化的扩缩容决策矩阵QPS变化RT变化TPS变化决策动作↑↑↑→↑提前预热备用集群↑↑↑→立即扩容限流↓↓↓→↓缩容资源回收→↑↑↑↓↓紧急回滚故障转移在实际运维中我们发现最有效的监控看板应该包含这些核心指标实时流量面板入口QPS、各服务TPS健康度雷达图P50/P90/P99 RT资源水位图CPU/内存/连接池使用率业务指标转化率、错误码分布