接口并发测试就是模拟多用户在同一时间调用同一个接口，检验系统在高负载下的表现。

一、需要做什么

1. 测试目的

性能标准：比如要求重要接口在 1000 QPS 下，P99 响应时间 < 200ms。

找短板/极限：系统在什么并发量下开始变慢、报错或崩溃。

稳定性测试：长时间（如 8 小时）高压下是不是有内存泄漏、连接不释放等问题。

2. 选被测接口和场景

优先测高频、重要业务接口（下单、支付、查询）。

整理调用链：接口是不是依赖登录态？是不是需要先调用 A 接口获取 token？按业务比例混合压测才更真实。

是单接口压测，还是多接口混合情形（如 80% 查询 + 20% 写入）？

3. 准备压测数据

参数化：用户名、手机号、订单号等绝不能写死，要准备大量唯一数据，避免缓存透过或业务思路错误（如重复下单）。

数据隔离：最好在独立的压测环境，或者在生产隔离的账号/数据标记下进行，防止脏数据污染业务。

处理登录态/鉴权：如果是需要 token 的接口，脚本里要自动完成登录并动态替换 token。

4. 环境和监控准备

独立的压测环境：和生产等比例缩小或直接使用生产（需谨慎），保证数据库、缓存、消息队列等依赖都有。

监控全包括：

应用层：QPS、响应时间、错误率（压测工具本身记录）。

服务器层：CPU、内存、磁盘 IO、网络带宽（Prometheus + Grafana，或云厂商监控）。

中间件层：数据库连接数、慢查询、Redis 命中率、消息积压等。

发压机准备：单台发压机的并发能力有限（受网络、端口数限制），高并发需要用多台发压机（分布式压测），并保证发压机带宽不成为短板。

5. 工具选择

JMeter：GUI + 命令行，生态全，适合大多数 HTTP/gRPC 接口，学习成本低。

Locust：纯 Python 写脚本，灵活度高，适合复杂业务思路压测，分布式方便。

wrk / wrk2：C 语言编写，单机并发能力极强，适合简单 HTTP 接口的快速极限测试。

K6：Go + JS 脚本，可集成到 CI/CD，适合不断性能测试。

云压测服务（PTS、LoadRunner Cloud 等）：模拟海量并发，省去自建发压环境。

二、怎么做

第1步：编写并调试压测脚本

以JMeter为例，结构一般是这样：

线程组：设置并发用户数（线程数）、启动时间、循环次数/不断时间。

HTTP请求默认值：配置被测域名、端口，减少重复。

前置处理器：如 用户参数或 BeanShell生成随机数据、处理签名。

HTTP请求：填入途径、方法、参数、Header（如动态 token）。

同步定时器（Synchronizing Timer）：真正意义上的“并发”重要。放在请求前，设置集合点（如每凑够 100 个线程同时释放），模拟瞬间尖峰。

后置处理器：提取响应中的 token 等，通过正则/JSON 提取器传给后续请求。

断言：判断返回值状态码、业务 code，只有正确响应的才算成功。

监听器：观察结果树（调试时用），压测时要禁用，只用“聚合报告”“汇总图”等写入文件的方式收集数据。

调试时用 1~2 个线程，保证业务思路通顺，断言生效，无脚本错误。

第2步：设计加压方法

不要一上来就打满，要分阶段注入，给系统预热和观察的时间窗口：

阶梯式加压：

如目的并发 500，可以分 100 → 200 → 300 → 400 → 500，每个阶梯不断 5 分钟，观察标准变化，找到性能拐点。

固定并发：设定目的并发直接跑，看稳定性。

脉冲/尖峰测试：几秒内把并发冲高再回落，模仿秒杀、抢购。Synchronizing Timer 很适合做这个。

长时间测试：用 70%~80% 最大容量，不断跑 8~24 小时，看内存、GC、连接泄漏。

第3步：执行和实时监控

启动压测工具的命令行方式（JMeter 绝对不要用 GUI 跑大量并发，用 jmeter -n -t script.jmx -l result.jtl）。

同时打开监控大屏：盯着应用 QPS、响应时间的 P99、错误率；服务器的 CPU、内存；数据库的活跃连接数。

一旦出现大量错误、响应时间飙升或服务器宕机，立刻停止，分析原因，不要盲目冲量。

第4步：结果分析和调优

收集这些标准，并做出判断：

吞吐量 (QPS)：能不能达到目的？

响应时间：平均、P95、P99、Max。P99 是重点，长尾请求影响体验。

错误率：业务错误还是系统错误（超时、拒绝连接、500）。

资源使用率：CPU 打满了吗？内存是不是不断增长？数据库连接池是不是耗尽？

定位方向：

错误率高 + 应用 CPU 低 → 下游依赖慢或挂了，检查数据库、Redis、外部 API。

QPS 上不去 + 应用 CPU 高 → 业务代码有性能短板，可以 profiler 分析热点方法。

响应时间波动大 + 数据库连接池满 → SQL 慢、未建索引或连接池太小。

根据发现的问题进行代码优化、配置调整，然后再次压测证实，这是一个螺旋上升的过程。

三、必须避坑

客户端短板

发压机 CPU、内存、网络先打满，得到的不是服务器性能。必须监控发压机资源，多机分布式施压。

数据重用导致缓存

如果 1000 个线程都在查同一个用户 ID，数据库/Redis 缓存命中率很高，测不出真实能力。一定要用大量分散的参数。

登录态过期

一个 token 用到底，跑一会全 401。脚本要能在登录失败或 token 过期时自动重新登录获取。

把集合点当万能

Synchronizing Timer 会阻塞线程，真实线上不会全都瞬间卡在一个请求上。混合情形里适度使用，测试尖峰冲击力。

未清理测试数据

压测产生的大量日志、订单、对账文件，可能撑爆磁盘或影响后续流程，结束要有清理机制。