1. 性能压测基础概念

性能压测是支付订单系统上线前必须通过的“大考”。它通过模拟真实用户与高并发请求,在受控环境下对系统施加负载,从而测量系统的响应能力、稳定性和资源消耗。对于支付系统而言,一次失败的压测可能意味着线上资损或订单丢失,因此理解其核心概念是构建可靠压测方案的第一步。

1.1 什么是性能压测

性能压测(Performance & Stress Testing)是一种通过自动化工具模拟多用户、高并发场景,向被测系统发送业务请求,并监控系统行为与性能指标的测试方法。其本质是回答三个问题:

  • 系统能处理多少并发请求?
  • 在多高负载下系统会开始变慢或出错?
  • 系统在极限压力下是否仍能保持数据一致性和可用性?
支付系统压测的特殊性: 支付订单涉及资金流转,压测时必须确保幂等性校验、事务回滚、对账机制在高压下依然正确。压测数据必须在压测结束后彻底清理,避免污染生产环境。

1.2 性能压测的目标

性能压测并非单纯“把系统打垮”,而是围绕以下四个核心目标展开:

目标维度 具体描述 支付系统示例
容量验证 确认系统在预期业务峰值负载下能否正常运行 双十一零点每秒 10 万笔下单请求
稳定性评估 验证系统在长时间持续负载下是否存在内存泄漏、连接池耗尽等问题 持续压测 4 小时,观察订单处理成功率
瓶颈定位 找出系统中最先达到性能极限的组件(数据库、缓存、网络等) 发现数据库连接池在 2000 并发时成为瓶颈
弹性与降级 测试系统在部分服务不可用时,降级策略是否生效 模拟支付网关超时,验证本地重试队列是否正常工作

1.3 关键性能指标

在支付订单系统的压测中,以下五个指标是衡量系统性能的核心标尺。它们相互关联,必须综合解读。

1.3.1 TPS 与 QPS

TPS(Transactions Per Second) 和 QPS(Queries Per Second) 是最常被混淆的两个指标。在支付场景中,它们的区别至关重要:

指标 定义 支付系统典型场景 说明
TPS 每秒完成的事务数(一个完整业务操作,通常包含多次请求) 一笔订单从“创建”到“支付成功”的完整流程 更贴近真实业务吞吐能力
QPS 每秒查询/请求数(单次请求或查询) 查询订单状态、查询用户余额 常用于衡量接口级吞吐
支付压测黄金法则: 优先关注 TPS,因为支付系统是典型的事务密集型系统。一个支付事务可能包含 5-8 次内部 RPC 调用,仅看 QPS 会高估系统处理真实业务的能力。

1.3.2 RT(响应时间)

响应时间(Response Time)指从客户端发送请求到收到完整响应所经过的时间。在支付系统中,RT 通常分为:

  • 平均响应时间(Avg RT): 所有请求响应时间的算术平均值,容易受极端值影响。
  • 百分位响应时间(P99/P95/P90): 表示 99%/95%/90% 的请求响应时间低于该值。支付系统通常要求 P99 RT < 500ms。
  • 最大响应时间(Max RT): 最慢请求的响应时间,通常用于排查异常。

1.3.3 并发数

并发数(Concurrency)指同一时刻系统正在处理的请求数量。它不等于“每秒请求数”,而是“系统中同时活跃的请求数”。在 JMeter 中,并发数由线程组控制。

并发数与 TPS、RT 的关系由 Little's Law 描述:

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

例如:若系统 TPS 为 5000,平均 RT 为 0.2 秒,则并发数约为 1000。这意味着 JMeter 只需设置 1000 个并发线程即可达到 5000 TPS 的吞吐量。

1.3.4 吞吐量

吞吐量(Throughput)是系统在单位时间内处理请求或数据的总量。在支付系统中,吞吐量通常以 TPS 或 订单数/秒 来衡量。吞吐量受限于系统中最薄弱的环节(瓶颈),压测的核心目标之一就是找到并消除这些瓶颈。

性能压测核心指标关系图 并发数 (Concurrency) TPS (事务/秒) RT (响应时间) 吞吐量 (Throughput) Little's Law Little's Law 决定 影响 公式:并发数 = TPS × 平均RT(秒)。提高TPS或降低RT,都能在相同并发下获得更高吞吐量。

1.4 指标间的权衡与典型场景

在支付订单系统的压测中,指标之间往往存在权衡关系。以下表格总结了常见场景下的指标表现:

场景 并发数 TPS 平均RT P99 RT 典型瓶颈
正常业务峰值 2000 8000 250ms 500ms 数据库连接池
缓存命中率高 3000 15000 200ms 400ms 网络带宽
数据库慢查询 1500 3000 500ms 2000ms SQL 索引缺失
外部支付网关超时 1000 1000 1000ms 5000ms 第三方接口
常见误区: 不要只关注平均 RT。在支付系统中,P99 RT 更能反映真实用户体验。如果平均 RT 为 200ms 但 P99 达到 2s,意味着 1% 的用户需要等待 2 秒以上,这在支付场景中极易导致用户放弃支付或重复提交订单。

1.5 压测类型与选择

根据测试目标的不同,性能压测可分为以下几种类型。支付系统通常需要组合使用:

  • 基准测试(Baseline Test): 在低并发(如 1 个用户)下运行,获取系统的基础性能数据,作为后续对比的参照。
  • 负载测试(Load Test): 模拟预期业务峰值负载(如 80% 预估峰值),验证系统能否稳定运行。
  • 压力测试(Stress Test): 持续增加负载直到系统崩溃或性能急剧下降,找出系统的极限容量。
  • 稳定性测试(Endurance Test): 在中等负载下持续运行较长时间(如 4-8 小时),检测内存泄漏、连接池耗尽等问题。
  • 尖峰测试(Spike Test): 突然将负载从低水平提升到极高值,模拟秒杀或突发流量场景。
压测类型与负载曲线示意 时间 并发数 基准 负载测试 压力测试 尖峰测试 稳定性测试(持续4h+) 支付系统压测建议组合:先基准 → 再负载 → 后压力 → 最后稳定性验证

1.6 本章小结