什么是压测：系统上线前的 “流量大考”，读懂压力测试完整方法论

步步糕升

导语

很多开发者对压测的理解停留在 “用工具疯狂调用接口，把系统打崩”。实际上压力测试（简称压测）是整套性能验证工程：在真实大流量到来之前，通过工具模拟大量用户、高并发请求与真实业务链路，探测系统的性能表现、稳定性、容量上限，提前找出性能瓶颈，为扩容、限流、降级、代码优化提供客观依据。
电商大促、秒杀抢票、新系统上线，如果跳过压测，真实流量涌入后很容易出现接口超时、订单异常、数据库打满等线上故障。压测的核心目标不是把系统打垮，而是提前暴露隐患，不让普通用户充当免费测试员。本文结合互联网行业最佳实践，讲解压测核心指标、测试分类、完整执行流程、常见瓶颈、安全红线与认知误区，适合后端、测试、运维开发者阅读。

一、压测核心观测指标

压测不能只看单一峰值 QPS，必须结合吞吐、延迟、错误率、服务器资源综合判断。一个接口每秒能处理十万请求，但一半请求失败、响应十几秒，这个数字没有任何业务价值。
业务链路指标

• QPS：每秒请求数，适合统计接口调用频次。
• TPS：每秒事务数，代表完整业务流程（下单‑扣库存‑支付）处理能力。
• RT 响应时间：请求从发起到返回的耗时。
• P95 / P99 分位延迟：P95 代表 95% 的请求耗时低于该数值；P99 代表 99% 请求耗时低于该数值。相比平均值，分位延迟更能反映真实用户体验，线上故障大多来自长尾慢请求。
• 错误率：超时、拒绝、业务异常请求占比，核心链路一般要求错误率趋近于 0。
• 并发数：同时发起请求的虚拟用户数量。
  

底层资源指标

CPU 使用率、内存占用、GC 停顿、磁盘 IO、网络带宽；数据库连接数、慢查询、锁竞争；缓存命中率；消息队列堆积量；线程池、连接池队列长度。

关键经验：压测有效结果 = 错误率可控 + 响应时间满足业务 SLA + 资源留有安全余量下，系统可稳定承载的流量。

二、六种常见压测类型

不同压测目标不一样，不要混为一谈。

• 基准测试：在固定环境测出系统基础性能基线，作为后续版本对比参照。
• 负载测试：逐步提升流量，观察系统在不同负载下各项指标变化，找到平稳运行区间。
• 压力测试：持续加压直到系统接近极限甚至报错，定位系统瓶颈与崩溃临界点。
• 稳定性测试（长稳测试）：中等压力长时间跑数小时甚至数天，检测内存泄漏、连接泄漏、资源缓慢累积耗尽等隐性问题。
• 峰值 / 尖峰测试：模拟秒杀、大促瞬间突发流量，验证系统抗冲击能力。
• 容量测试：评估当前硬件架构最多可支撑多少用户、订单、请求，指导机器扩容规划。
  

三、一次完整压测的标准执行步骤

• 明确压测目标目标要量化，例如 “下单链路稳定支撑 3000TPS，P99 延迟低于 800ms，错误率小于 0.1%”。没有明确目标，压测结果就无法评判好坏。
• 设计真实业务场景真实用户不会只调用单一接口，会包含登录‑浏览‑加购‑下单‑支付完整链路。业务压测尽量还原真实用户行为比例，避免只做单接口压测，忽略链路之间的资源竞争。
• 准备环境与测试数据压测环境配置、数据库数据量、缓存、中间件配置尽量贴近生产；环境差异过大会导致压测结果完全失真。
• 选择合适压测工具
  

• Locust：Python 脚本，擅长模拟复杂用户业务行为，支持分布式压测。
• k6：JS 脚本，云原生友好，易于接入 CI/CD 持续集成。
• Gatling：Scala，高并发性能优秀。
• wrk / ab：轻量 HTTP 工具，适合简单接口快速基准压测。
  

• 阶梯式执行压测不要一开始就打满最大压力，由低到高逐步提升并发，每一档压力稳定运行足够时间再采集指标。
• 全维度监控观测不只看压测工具输出，同时观测服务、数据库、缓存、消息队列、链路追踪、告警日志。很多瓶颈不会体现在接口返回，而是暴露在底层资源。
• 定位瓶颈、完成优化、复测验证找到性能短板，完成代码、索引、配置优化之后，重新压测验证优化是否生效。
  

四、系统常见性能瓶颈分布

性能瓶颈可能出现在全链路任意一环，不能只盯着应用接口 QPS 看。

• 应用服务层：复杂业务逻辑、锁竞争、线程池配置不合理、频繁对象创建导致 GC 卡顿。
• 数据库层：缺少索引、大量慢查询、事务过长、热点行竞争、数据库连接池耗尽。
• 缓存层：缓存命中率低、热点 Key、缓存穿透、缓存击穿。
• 中间件：消息队列消息堆积，消费者处理速度跟不上生产速度。
• 网络与网关：带宽打满、连接数限制、网关限流。
• 第三方依赖：调用外部支付、短信、风控接口响应慢，拖垮整条业务链路。
  

五、压测必须遵守的安全红线

严禁未经审批直接对线上生产环境做高强度压测，会直接造成线上故障，影响真实用户。

• 优先在预发、性能测试环境执行压测；环境尽量还原生产配置。
• 如果确需线上压测：必须完整审批、选择业务低峰时段、配置限流隔离、完善监控与应急预案。
• 使用影子库、影子表、流量染色、测试账号，不能生成脏订单、脏支付、大量垃圾短信，污染真实业务数据。
  

配套体系：压测用来摸清系统容量边界；限流、熔断、降级用来保护线上。压测告诉我们系统最多扛多少流量；限流在超过阈值之后保护系统；熔断防止下游故障连锁扩散；降级在高峰临时关闭非核心功能，保障下单、支付等核心链路优先可用。

六、重要工程理念：压测不是一次性工作

系统代码迭代、数据量上涨、机器配置变更、缓存策略调整、流量模型变化，都会改变系统性能表现。大促前临时抱佛脚式压测远远不够。成熟团队会把性能压测纳入持续工程，版本迭代中持续回归性能基线，及时发现版本引入的性能退化问题。
七、开发者高频认知误区澄清

误区 1：压测就是把系统打崩，打崩才算完成压测

纠正：压测核心价值是提前发现瓶颈，评估安全容量；很多业务场景不需要打到崩溃点，找到稳定可运行的上限就足够。
误区 2：只看 QPS 峰值数字，就评判系统性能好坏

纠正：必须配套看错误率、P95/P99 延迟、资源占用。高 QPS 伴随大量超时失败没有业务意义。
误区 3：只压单个接口就代表全链路性能

纠正：单接口压测表现很好，串联完整业务链路后会出现资源竞争，真实性能会下降，重要业务要做全链路压测。
误区 4：平均响应时间可以代表用户体验

纠正：平均值会掩盖长尾慢请求，1% 的慢请求会影响大量真实用户，P95、P99 分位延迟优先级远高于平均值。
误区 5：压测做一次就可以一劳永逸

纠正：代码、数据量、配置发生变化，性能就会改变，需要持续回归验证。
误区 6：可以随便拿生产环境做压测

纠正：线上压测风险极高，未经审批属于高危操作，优先使用性能测试环境。
全文总结

压测就是系统上线前一场可控的流量模拟大考。通过模拟真实用户流量，探测系统吞吐量、响应延迟、错误率，定位应用、数据库、缓存、中间件、第三方依赖的各类性能瓶颈，给出扩容、限流降级的客观依据。
压测不是追求打出漂亮的峰值数字，而是找到系统真实的安全容量边界；不能只看 QPS，P95/P99 长尾延迟、错误率、底层资源同样关键。遵守安全规范，优先在测试环境执行；同时压测不是一次性任务，需要伴随版本迭代持续做性能回归。压测、限流、熔断、降级配合在一起，共同构筑分布式系统的稳定性防线。