上周我用 Apifox 给黑马点评项目做了一轮多并发线程测试。黑马点评是很多 Java 后端同学拿来练手的 Spring Boot 项目里面既有商户查询这种典型的读多写少接口也有优惠券秒杀这种最容易出并发问题的写接口。我抱着“做个像样的自动化测试”的想法把登录、商户查询、秒杀下单三个接口串成一个场景再用 Apifox 的并发配置一次性开出几十个线程去压结果第一次跑就看到了 MySQL 连接池耗尽、库存被抢穿、线程间登录态冲突这一连串问题。这篇文章我把整个操作流程、参数设置逻辑和踩过的坑完整写下来给正在折腾黑马点评、或者想用 Apifox 给自己的项目做接口并发验证的朋友一个可以直接参考的模板。1. 先搞清楚黑马点评有哪些接口值得做并发测试1.1 黑马点评项目里最典型的并发风险点黑马点评这个项目的业务模型模仿的是生活服务类 APP核心模块包括用户登录、商户查询、优惠券秒杀、好友关注、探店笔记等。项目本身用的是 Spring Boot MyBatis Plus Redis MySQL 这套很标准的组合所以它暴露出来的问题在真实业务里也同样存在这也是为什么很多人拿它做压测和面试素材。要说哪些接口最值得做多并发线程测试我建议把精力放在三个地方。第一个是优惠券秒杀接口这是整个项目里并发复杂度最高的接口通常的版本会涉及 Redis 预减库存、分布式锁、异步队列、数据库乐观锁扣库存这些操作任何一个环节没有处理好并发一上来就会超卖或者重复下单。第二个是商户查询接口它是典型的读多写少场景走 Redis 缓存兜底适合用来测缓存命中和接口吞吐量。第三个是登录接口每次登录都会生成 token 并写入 Redis高并发下token的写入和校验本身也是一种压力。风险点要分清楚秒杀接口关注的是数据正确性也就是并发下库存对不对、用户是否被限购商户查询接口关注的是可用性和响应速度能不能扛住突发流量登录接口关注的是 Redis 写入并发和 token 校验链路。不同接口的测试目标完全不同不能只拿一个接口代表整个项目。我见过不少人拿 Apifox 只测了一个 /api/shop/{id} 就自称做了压力测试那其实只能叫接口冒烟。1.2 多并发线程测试在 Apifox 里到底是什么很多人对 Apifox 的认知还停留在“接口调试工具”这个层面实际上它的自动化测试模块早就支持多并发场景了。在 Apifox 里做多并发线程测试本质上是把接口作为测试场景里的步骤然后为每个步骤配置虚拟用户数量和运行时长让工具同时发出多个请求去访问同一个接口。这里要澄清一个概念Apifox 里的“线程数”并不是操作系统级别的线程而是虚拟用户的抽象。每个虚拟用户会按照你设置的延时和循环次数不断发送请求比如设置 50 个线程跑 30 秒实际含义就是模拟 50 个用户在这段时间内持续操作而不是真的只有 50 个 HTTP 请求。这个逻辑和 JMeter 的线程组很接近只不过 Apifox 把配置界面做得更友好不需要写脚本。用一个生活化的类比来解释单接口调试就像一个人去餐厅点一份菜结果正常多并发测试就像 100 个人同时挤进餐厅抢同一道限量的菜你要看的是厨房会不会崩、会不会有人拿到重复的号、会不会有人明明抢到了却被告知卖完了。Apifox 做的事情就是帮你把这 100 个人同时推到接口面前然后记录每道菜出餐的耗时和失败情况。需要说明的是Apifox 的性能测试能力更适合中小规模的并发验证几十到几百个虚拟用户这个量级它能处理得很稳。如果要做上万级并发的专业性能测试那还是得用 JMeter 或者专门的压测平台这个话题后面我会单独说。1.3 这次测试我要回答的具体问题测试不能漫无目的地跑开始之前我给自己定了几个明确的问题。第一50 个并发用户同时抢同一张秒杀券数据库里会不会出现库存扣成负数的情况也就是超卖。第二同一个用户用同一个 token 反复提交秒杀请求系统能不能正确拦截做到一人一单。第三商户查询接口在 20 个并发线程下的平均响应时间和错误率是否在一个健康范围。第四秒杀接口在并发时后端连接池和 Redis 连接池是否够用有没有明显的资源等待。这些问题对应到 Apifox 的测试设计上就变成了三个关键配置多线程数、运行时长、断言规则。线程数决定了压力的强度运行时长决定了样本量是否足够断言规则决定了你怎么判断“成功”和“失败”——注意这里说的失败不是 HTTP 500而是业务上的失败比如返回了库存不足或者已购买。黑马点评的接口返回格式是统一的 JSONcode 为 1 表示成功code 为 0 或者其他值表示业务失败所以断言规则要同时检查 HTTP 状态码和业务状态码。我最后给自己定了一个验收标准在 50 线程、30 秒的压测下错误率低于 1%平均响应时间低于 800 毫秒并且秒杀接口不能出现超卖和重复下单。这个标准不算苛刻但足以暴露出项目在默认配置下的问题事实上也确实暴露了。2. 环境准备把黑马点评跑起来并接入 Apifox2.1 本地启动依赖和项目的具体步骤要跑黑马点评本地需要三个基础环境MySQL、Redis 和 JDK 8 以上。MySQL 用来存商户、用户、优惠券、订单这些业务数据Redis 用来存验证码、token、缓存商户信息和秒杀库存。项目启动前先得建库黑马点评的 SQL 脚本一般在项目的 sql 目录下导入后会自动建好 hmdp 库和所有表。配置文件 application.yaml 里需要重点检查几项数据库连接地址和密码、Redis 的 host 和端口。如果本地 MySQL 和 Redis 用的都是默认端口和 root 账号那基本只需要改密码。启动项目可以用 IDEA 直接运行主类也可以在项目根目录执行 mvn spring-boot:run。项目默认跑在 8080 端口启动成功后访问商户查询接口能返回数据就说明环境通了。有一个细节很多新手容易卡住短信验证码。黑马点评的发送验证码接口在本地环境不会真的发短信验证码通常是写入 Redis 的你需要在登录前先调用发送验证码接口然后去 Redis 里看实际的验证码值或者直接把项目代码里的验证码生成逻辑改成固定值方便调试。我自己的做法是看 UserController 里的实现如果你的版本里有写死的验证码就直接用没有就改成固定返回 123456这样登录流程会顺畅很多。2.2 把接口导入 Apifox 并配置环境变量Apifox 接入项目接口有两条路。如果黑马点评项目自带了 postman 集合文件直接在 Apifox 里选择“导入 Postman 数据”就能把接口和目录结构都带进来省事。如果找不到集合文件就手动建一个项目目录把登录、验证码、商户查询、秒杀这些接口逐个加进去请求路径按你本地项目实际的路由来填。我建议路径上一律以 /api 开头黑马点评的接口基本都是这个风格比如 POST /api/user/login、GET /api/shop/{id}、POST /api/voucher-order/seckill/{id}。接口导入后一定要配置环境变量。用 Apifox 的人都习惯在右上角的环境管理里新建一个“本地环境”里面加一个 baseUrl 变量值填 http://localhost:8080。然后所有接口请求路径都写成 {{baseUrl}}/api/xxx 这种形式。这么做的好处是后续切到测试环境或者换端口只需要改一个变量不需要改每个接口的 URL。我自己已经吃过没配环境变量的亏接口多一点之后改起来非常痛苦。配置环境时还有一个小建议把请求超时时间调大一点。Apifox 默认超时时间是 10 秒本地压测时如果后端连接池被打满很多请求会一直卡在等待连接的阶段超时设置太短会导致误判失败。我通常把超时时间调到 30 秒这样能区分出是请求真的失败还是只是慢。2.3 登录态处理并发场景下不能共用一个 Token黑马点评的登录流程是先调用发送验证码接口拿到 Redis 里的验证码再调用登录接口服务端校验通过后返回 token。后续业务请求都要在请求头里加 authorization值为 token。在 Apifox 里单接口调试时最省事的做法是登录后把 token 复制到环境变量里所有接口共用。但在多并发线程测试里这个问题就复杂了。因为黑马点评的秒杀业务有“一人一单”的限制如果你让 50 个线程全部共用同一个 token等于这 50 个线程在服务端看来全是同一个用户。一个用户抢到券之后后面的请求全部会被判定为“已购买”或者触发重复下单拦截测试结果里会全是业务失败。这不是并发能力的问题是测试数据设计的问题。正确的做法是准备多个手机号提前逐个调登录接口生成多个 token然后在 Apifox 的并发测试里通过数据文件的方式给每个虚拟用户分配不同的 token。具体操作是把几十个手机号对应的 token 整理成一个 JSON 或 CSV 文件在测试场景的数据源配置里引入这个文件接口请求头的 authorization 值改成引用数据字段比如 {{data.token}}。这样每个虚拟用户拿到的都是独立的登录态才能真正测出“多个用户同时抢券”的效果。我准备 token 的过程也很简单写了一段循环调用登录接口的脚本把返回的 token 收集起来输出成文件。手动复制当然也行但多了之后效率太低了建议直接用 Apifox 的测试数据文件功能。3. 核心环节在 Apifox 里搭建并发线程测试场景3.1 创建自动化场景和添加并发步骤打开 Apifox 的“自动化测试”模块新建一个测试场景名字可以叫“黑马点评并发测试”。场景里的每个接口就是一个步骤步骤顺序建议按业务流程来比如先调优惠券查询接口确认数据状态再调秒杀接口最后查订单列表。但这里有一个关键点性能测试不是把每个接口串行执行而是要针对目标接口设置并发让该接口在整个运行周期内被反复并发调用。在 Apifox 的步骤配置中每个接口步骤都有并发相关的设置。以我常用的版本为例运行模式可以配置虚拟用户数、持续时间、线程间延迟、失败停止开关等。不同版本的入口名称可能有差异有的叫“并发配置”有的叫“线程组”但核心参数都是这几个。虚拟用户数代表同时发起请求的线程数持续时间代表测试跑多久线程间延迟代表每个虚拟用户两次请求之间的间隔时间。配置并发测试时有一个容易混淆的地方一个场景里多个接口步骤可以有不同的并发策略。比如登录接口只需要在准备阶段跑几次拿 token不用并发商户查询接口可以用 20 个线程做轻量压测秒杀接口才是主角设置 50 个线程重点观察。Apifox 支持给每个步骤单独配置虚拟用户数这样能模拟更真实的业务混合流量。我建议每个步骤都打开“响应断言”至少检查 HTTP 状态码是 200并且对于关键业务接口再加上 JSON 断言。Apifox 的断言功能有点像 Postman在步骤后置操作里添加断言脚本可以直接用 pm.expect 这种写法也可以选择界面化的断言配置。断言的作用是让压测结果能区分“请求成功”和“业务成功”没有断言的话接口即使返回了业务失败的 JSON也会被统计成成功请求。3.2 多并发线程参数怎么填才合理这里的参数设置是整个测试方案的核心我针对商户查询接口和秒杀接口分别给出了配置。商户查询接口我用了 20 个虚拟用户持续 30 秒线程间延迟为 0 毫秒。选择 20 而不是一开始就上 50是因为商户查询接口走了 Redis 缓存正常情况下响应很快20 个线程已经能产生足够的请求量来观察吞吐曲线。如果 20 线程表现稳定再逐步加到 50 去测试极限。秒杀接口的并发配置是 50 个虚拟用户、持续 30 秒、线程间延迟 0 毫秒、失败停止关闭。为什么是 50因为本地开发机的资源有限50 个并发用户已经足够把 Tomcat 默认线程池和 HikariCP 连接池的压力打出来又不会让整个机器立刻卡死。首次跑测试的人建议从 10 到 20 开始确认脚本没问题再逐步升到 50最后如果想看崩溃点可以上 100。持续时间选 30 秒的理由也很简单时间太短比如只有 5 秒产生的请求样本不足TPS 和错误率数据都没有统计意义时间太长比如 5 分钟秒杀库存早就被消耗完后面所有请求都变成“库存不足”数据同样没有参考价值。线程间延迟为什么选 0 毫秒因为我想压的是“同时涌入”的最坏情况0 延迟可以让所有虚拟用户尽可能密集地发请求把并发问题最大化暴露。如果你更想模拟真实用户操作的平均节奏可以把延迟设置成 100 到 500 毫秒这样趋向于稳定性测试而不是冲击测试。对于首次摸底我建议先用 0 延迟做一次再用 100 毫秒做一次两次数据对比会非常有价值。失败停止开关一定要关掉。如果某个请求因为瞬时网络抖动失败开关开着会导致整个场景提前终止测试数据就废了。正确的做法是允许失败发生最后在报告里看错误率分布。3.3 秒杀接口的专属配置和数据准备秒杀接口的测试比普通查询接口要复杂因为它的前置条件特别多。第一秒杀券必须在数据库里有库存而且 Redis 里的库存预热要和数据库一致。黑马点评的秒杀券库存通常存在 tb_voucher 表的 stock 字段里有些版本还会在 Redis 里维护一个库存 key。跑测试前我习惯先查一下当前库存如果库存已经被上一次测试消耗完就执行一句 UPDATE tb_voucher SET stock 100 WHERE id 1 来重置同时把对应 Redis 库存也重新设置一遍。第二秒杀接口的请求头必须带着独立的 token。这一步在前面已经强调过了实际配置就是在请求头的 authorization 字段里引用数据文件中的变量而不引用环境变量里那个共用的 token。我准备的测试数据文件是一个 CSV包含约 50 组用户手机号和 token正好对应 50 个虚拟用户。第三断言要分成两层。第一层检查 HTTP 状态码是 200这一层判断网络和后端服务是否正常。第二层检查响应体中的 code 字段如果业务返回 code 不等于 1说明这个请求虽然在 HTTP 层面成功了但业务上是失败的——可能是库存不足、已经购买也可能是参数错误。在 Apifox 的统计报告里断言失败会被单独计入失败数这样你就能从失败数里看出是性能问题还是业务限制。这里要提醒一个版本差异问题。如果你用的黑马点评是较新的异步下单版本秒杀接口的流程是先通过 Redis Lua 脚本扣减库存然后把下单消息写入 Redis Stream由消费者线程异步创建订单。这种情况下秒杀接口本身返回成功只代表“库存预扣成功、消息入队成功”并不代表订单一定创建成功。所以压测时除了看 Apifox 的报告还要盯着后端日志看消费者线程有没有报错、Stream 里有没有积压消息。如果是早期的同步下单版本那逻辑会更直接但并发下出现超卖和性能瓶颈的速度反而更快。3.4 断言和数据隔离的正确姿势很多人做压测时忽略断言结果报告里一堆 HTTP 200就以为接口没问题。其实在黑马点评这种业务里HTTP 200 只是最基本的门槛。我建议你在设置并发测试前先单接口调试几次看清楚成功和失败的响应体长什么样然后把断言配置好再开跑。以秒杀接口为例成功时响应体的 code 是 1返回的 data 里有订单 id失败时 code 是 0错误信息可能是“库存不足”或者“请勿重复下单”。我配置断言的方式是先在“后置操作”里写一段 pm 脚本读取响应体中的 code 字段pm.expect(json.code).to.eql(1)这样只要业务失败就会被标记为断言失败。其它接口也一样商户查询接口断言 code 为 1登录接口断言返回数据里包含 token 字段。数据隔离这块除了前面说的多 token 数据文件还有一个很容易被忽略的点订单表的数据污染。秒杀测试每跑一次tb_voucher_order 表就会多出一批订单第二次跑的时候再拿同一批手机号去抢同一张券会被限购拦截。所以我在压测前会写一个重置脚本包含三件事把测试券的库存恢复、把 Redis 里的库存 key 重置、把测试期间生成的订单记录清空。跑一次测试前执行一次这个脚本能保证每次压测都是在干净的数据基础上进行。4. 实测摸底与结果分析4.1 商户查询接口的 20 线程基线测试我先跑商户查询接口作为基线参考。配置是 20 个虚拟用户持续 30 秒线程间延迟 0 毫秒。这个接口没有写操作查询链路简化下来就是请求进来走 Redis 缓存缓存未命中才回源数据库所以整体响应非常快。我这边实测的数据大概是这样30 秒内发送了约 3000 个请求TPS 在 100 左右平均响应时间约 25 毫秒错误率为 0个别请求因为本地机器资源波动的 p99 延迟到了 80 毫秒左右。这个结果说明在 20 并发下商户查询接口本身和底下的 Redis 链路都没有明显瓶颈。不过要注意一个边界如果你的压测请求里带上了让缓存失效的参数或者第一次压测时 Redis 里根本没有缓存数据你会看到一批请求回源数据库响应时间会明显变长。黑马点评的商户查询逻辑里有一个缓存重建的步骤并发下可能出现缓存击穿不过那是另一个话题这次我因为之前已经单独调过接口Redis 里的缓存已经建好了所以数据比较干净。4.2 秒杀接口 50 线程的第一次压测秒杀接口我配置了 50 个虚拟用户、30 秒时长、0 延迟使用准备好的 50 组 token 数据文件。第一次跑完Apifox 报告里显示总请求数约 1200TPS 只有 40 左右平均响应时间达到了 900 毫秒以上错误率接近 10%断言失败率更高。TPS 只有 40 意味着什么意味着 50 个并发用户同时涌入时大量请求被排队等待服务端没有能力快速处理完。配合后端日志看问题非常明显Tomcat 线程池虽然远没打满但数据库连接池先撑不住了。黑马点评默认的 HikariCP 最大连接数是 1050 个并发请求同时来了每个秒杀请求要查库存、扣库存、建订单一顿操作下来几乎把 10 个连接全占住了后面的请求只能等在连接池的队列里等待超时之后就报错。日志里出现了大量类似 connection is not available, request timed out after 30000ms 的异常。除了连接池问题我还看到了一个业务层面的现象断言失败里有一批是“请勿重复下单”。这就验证了我前面的判断如果数据文件没配好50 个线程共用 token 就会这样但这次我用了独立 token为什么还会重复下单查了日志才想起来是因为秒杀接口本身没有做接口幂等快速连续提交的两个请求都通过了校验只是后来事务回滚才挡住了一部分。这其实暴露了黑马点评在并发控制上的一个经典问题后面排查章节我会细说。4.3 调优后重跑连接池参数调整前后对比问题定位到连接池之后我做了几处调整。第一把 HikariCP 的最大连接数从默认的 10 调到 30配置项是 spring.datasource.hikari.maximum-pool-size。第二把 Tomcat 的最大线程数从默认的 200 调到 500配置项是 server.tomcat.threads.max。第三把 Redis 连接池的 max-active 从默认值调大到 50因为秒杀逻辑里查库存、写订单都有 Redis 操作。为什么调成 30 而不是更大我不建议盲目调大。按照 50 个并发用户、每个请求平均耗时 300 毫秒来估算同一时刻大约有 15 到 20 个请求在执行数据库操作30 个连接已经有接近 1.5 倍的余量足够应对响应时间的波动。如果你把连接池调到 200反而会因为数据库服务器资源不足让连接都在等待性能并不会线性提升。调完参数重启项目重新跑同样的 50 线程 30 秒场景结果改善非常明显TPS 从 40 提升到了 130 以上平均响应时间降到约 300 毫秒错误率降到 0断言失败里剩下的基本是“库存不足”和“已购买”这类正常的业务拦截。调优前后的对比表格我列在这里供你参考。指标调优前调优后虚拟用户数5050总请求数约 1200约 3900TPS约 40约 130平均响应时间约 900ms约 300ms错误率约 10%不到 1%主要失败原因连接池超时业务限购/库存不足注意这些数字是本地机器的相对值不代表项目上线后的真实性能但优化前后的趋势是真实的。我只改了两个参数就把吞吐量翻了三倍这正说明了“压测不是测机器跑得有多快而是测配置和代码有没有挡住性能”这句话。5. 踩坑记录与排查心得5.1 所有线程共用 Token 导致大量业务失败这是新手最容易踩的坑。第一次压测时我偷懒直接在环境变量里放了一个 token所有虚拟用户共用。结果秒杀接口的错误率高达 80%报告里全是“请勿重复下单”。一开始我还以为是并发能力问题后来一看后端日志才发现50 个线程全被识别成同一个用户第一波请求抢到券之后后续请求全部被限购拦截。解决方式前面说过就是用数据文件给每个虚拟用户分配独立 token。这里再补充一个细节token 文件里的手机号不要重复因为黑马点评的限购逻辑是按用户 ID 判断的手机号重复等于用户 ID 重复。我自己生成数据文件时直接用了 50 个不同的手机号跑完登录接口后再手动核对了一遍 token 非空。5.2 库存和订单数据污染第二次测试结果失真第一次跑完秒杀我以为可以直接跑第二轮做对比结果库存早就被抢光了所有请求都返回“库存不足”TPS 看着还行但断言失败率 100%数据完全没有价值。这就是测试数据污染。解决办法是写一个重置脚本放在项目目录里每次压测前执行。脚本做的事情很简单把秒杀券的数据库库存 update 回初始值把 Redis 里的库存 key 重新设一遍把本次测试产生的订单记录 delete 掉。如果你用的是异步下单版本还要注意 Redis Stream 里可能残留的未消费消息最好在重置时也清理掉。我实测下来这个脚本能让我一天内反复跑几十轮压测每轮数据都是干净可比的。5.3 后端连接池和线程池不调就跑错误率直线上升黑马点评默认的 HikariCP 最大连接数是 10这对日常开发完全够用但在 50 并发的压测下就是灾难。我在调优前跑的那轮测试里大量请求卡在“等待数据库连接”这个环节最终超时报错。更隐蔽的是Tomcat 的线程池虽说是 200但当连接池耗尽时线程都阻塞在获取连接上线程池也很快被占满新请求直接排队。调参时要记住一个原则参数是配合业务场景的不是越大越好。连接池开太大数据库端并发上去后反而造成大量上下文切换线程池开太大内存占用增加GC 压力也上来。我在这次项目里选择 30 连接 500 线程是针对“单机本地 50 并发”这个场景的合理值。如果你的机器配置更高或者秒杀逻辑更简单可以自行调整。5.4 Apifox 做并发测试的边界和正确姿势用完整套流程后我对 Apifox 在并发测试上的定位有了更清晰的判断。它适合做中小规模的接口并发验证和自动化回归尤其是几十个虚拟用户这个量级配置方便、报告直观、能和接口调试无缝衔接。但如果你是做生产环境的容量评估、要精确控制压测曲线、要看更细粒度的服务器监控那还是用 JMeter 配合 Grafana 这类专业方案更合适。还有一个容易被忽略的问题Apifox 的压测机本身也是瓶颈。如果你在同一台笔记本上既跑项目、又跑 Apifox、还开着浏览器和录屏软件测试结果会掺入大量本地资源竞争的噪声。我建议跑压测时把能关的程序都关掉至少在报告里注明测试环境的资源状况否则数据没法横向对比。最后再分享一点个人体会这轮测试做完我最深的感受是压力测试的价值不在于得到一个漂亮的 TPS 数字而在于它逼着你去思考每个接口背后的依赖关系。黑马点评的秒杀接口看起来只是一个 POST 请求但它背后连着 Redis、MySQL、连接池、事务、限购规则任何一个环节出问题最终都会在并发场景里以错误率飙升的形式暴露出来。这次压测给我的收获除了数据更重要的是建立了“压测前先设计数据、压测中盯日志、压测后清理环境”这套操作习惯。最后再分享一个小技巧测试前把重置环境的 SQL 和 Redis 命令写成脚本命名成 reset.sh 或者放到测试文档里每次跑测试前执行一次。看起来是很小的一步但能让你在反复调参优化的过程中节省大量重复劳动也能保证每一轮测试的数据都是可比的。如果你正准备拿黑马点评去面试可以把 Apifox 生成的测试报告和优化前后的对比数据整理到项目介绍里一句“我用 Apifox 做了 50 线程的并发压测定位并调整了连接池参数将 TPS 从 40 提升到 130”比单纯说“我做了秒杀功能”要有说服力得多。
上周我用 Apifox 给黑马点评项目做了一轮多并发线程测试。黑马点评是很多 Java 后端同学拿来练手的 Spring Boot 项目里面既有商户查询这种典型的读多写少接口也有优惠券秒杀这种最容易出并发问题的写接口。我抱着“做个像样的自动化测试”的想法把登录、商户查询、秒杀下单三个接口串成一个场景再用 Apifox 的并发配置一次性开出几十个线程去压结果第一次跑就看到了 MySQL 连接池耗尽、库存被抢穿、线程间登录态冲突这一连串问题。这篇文章我把整个操作流程、参数设置逻辑和踩过的坑完整写下来给正在折腾黑马点评、或者想用 Apifox 给自己的项目做接口并发验证的朋友一个可以直接参考的模板。1. 先搞清楚黑马点评有哪些接口值得做并发测试1.1 黑马点评项目里最典型的并发风险点黑马点评这个项目的业务模型模仿的是生活服务类 APP核心模块包括用户登录、商户查询、优惠券秒杀、好友关注、探店笔记等。项目本身用的是 Spring Boot MyBatis Plus Redis MySQL 这套很标准的组合所以它暴露出来的问题在真实业务里也同样存在这也是为什么很多人拿它做压测和面试素材。要说哪些接口最值得做多并发线程测试我建议把精力放在三个地方。第一个是优惠券秒杀接口这是整个项目里并发复杂度最高的接口通常的版本会涉及 Redis 预减库存、分布式锁、异步队列、数据库乐观锁扣库存这些操作任何一个环节没有处理好并发一上来就会超卖或者重复下单。第二个是商户查询接口它是典型的读多写少场景走 Redis 缓存兜底适合用来测缓存命中和接口吞吐量。第三个是登录接口每次登录都会生成 token 并写入 Redis高并发下token的写入和校验本身也是一种压力。风险点要分清楚秒杀接口关注的是数据正确性也就是并发下库存对不对、用户是否被限购商户查询接口关注的是可用性和响应速度能不能扛住突发流量登录接口关注的是 Redis 写入并发和 token 校验链路。不同接口的测试目标完全不同不能只拿一个接口代表整个项目。我见过不少人拿 Apifox 只测了一个 /api/shop/{id} 就自称做了压力测试那其实只能叫接口冒烟。1.2 多并发线程测试在 Apifox 里到底是什么很多人对 Apifox 的认知还停留在“接口调试工具”这个层面实际上它的自动化测试模块早就支持多并发场景了。在 Apifox 里做多并发线程测试本质上是把接口作为测试场景里的步骤然后为每个步骤配置虚拟用户数量和运行时长让工具同时发出多个请求去访问同一个接口。这里要澄清一个概念Apifox 里的“线程数”并不是操作系统级别的线程而是虚拟用户的抽象。每个虚拟用户会按照你设置的延时和循环次数不断发送请求比如设置 50 个线程跑 30 秒实际含义就是模拟 50 个用户在这段时间内持续操作而不是真的只有 50 个 HTTP 请求。这个逻辑和 JMeter 的线程组很接近只不过 Apifox 把配置界面做得更友好不需要写脚本。用一个生活化的类比来解释单接口调试就像一个人去餐厅点一份菜结果正常多并发测试就像 100 个人同时挤进餐厅抢同一道限量的菜你要看的是厨房会不会崩、会不会有人拿到重复的号、会不会有人明明抢到了却被告知卖完了。Apifox 做的事情就是帮你把这 100 个人同时推到接口面前然后记录每道菜出餐的耗时和失败情况。需要说明的是Apifox 的性能测试能力更适合中小规模的并发验证几十到几百个虚拟用户这个量级它能处理得很稳。如果要做上万级并发的专业性能测试那还是得用 JMeter 或者专门的压测平台这个话题后面我会单独说。1.3 这次测试我要回答的具体问题测试不能漫无目的地跑开始之前我给自己定了几个明确的问题。第一50 个并发用户同时抢同一张秒杀券数据库里会不会出现库存扣成负数的情况也就是超卖。第二同一个用户用同一个 token 反复提交秒杀请求系统能不能正确拦截做到一人一单。第三商户查询接口在 20 个并发线程下的平均响应时间和错误率是否在一个健康范围。第四秒杀接口在并发时后端连接池和 Redis 连接池是否够用有没有明显的资源等待。这些问题对应到 Apifox 的测试设计上就变成了三个关键配置多线程数、运行时长、断言规则。线程数决定了压力的强度运行时长决定了样本量是否足够断言规则决定了你怎么判断“成功”和“失败”——注意这里说的失败不是 HTTP 500而是业务上的失败比如返回了库存不足或者已购买。黑马点评的接口返回格式是统一的 JSONcode 为 1 表示成功code 为 0 或者其他值表示业务失败所以断言规则要同时检查 HTTP 状态码和业务状态码。我最后给自己定了一个验收标准在 50 线程、30 秒的压测下错误率低于 1%平均响应时间低于 800 毫秒并且秒杀接口不能出现超卖和重复下单。这个标准不算苛刻但足以暴露出项目在默认配置下的问题事实上也确实暴露了。2. 环境准备把黑马点评跑起来并接入 Apifox2.1 本地启动依赖和项目的具体步骤要跑黑马点评本地需要三个基础环境MySQL、Redis 和 JDK 8 以上。MySQL 用来存商户、用户、优惠券、订单这些业务数据Redis 用来存验证码、token、缓存商户信息和秒杀库存。项目启动前先得建库黑马点评的 SQL 脚本一般在项目的 sql 目录下导入后会自动建好 hmdp 库和所有表。配置文件 application.yaml 里需要重点检查几项数据库连接地址和密码、Redis 的 host 和端口。如果本地 MySQL 和 Redis 用的都是默认端口和 root 账号那基本只需要改密码。启动项目可以用 IDEA 直接运行主类也可以在项目根目录执行 mvn spring-boot:run。项目默认跑在 8080 端口启动成功后访问商户查询接口能返回数据就说明环境通了。有一个细节很多新手容易卡住短信验证码。黑马点评的发送验证码接口在本地环境不会真的发短信验证码通常是写入 Redis 的你需要在登录前先调用发送验证码接口然后去 Redis 里看实际的验证码值或者直接把项目代码里的验证码生成逻辑改成固定值方便调试。我自己的做法是看 UserController 里的实现如果你的版本里有写死的验证码就直接用没有就改成固定返回 123456这样登录流程会顺畅很多。2.2 把接口导入 Apifox 并配置环境变量Apifox 接入项目接口有两条路。如果黑马点评项目自带了 postman 集合文件直接在 Apifox 里选择“导入 Postman 数据”就能把接口和目录结构都带进来省事。如果找不到集合文件就手动建一个项目目录把登录、验证码、商户查询、秒杀这些接口逐个加进去请求路径按你本地项目实际的路由来填。我建议路径上一律以 /api 开头黑马点评的接口基本都是这个风格比如 POST /api/user/login、GET /api/shop/{id}、POST /api/voucher-order/seckill/{id}。接口导入后一定要配置环境变量。用 Apifox 的人都习惯在右上角的环境管理里新建一个“本地环境”里面加一个 baseUrl 变量值填 http://localhost:8080。然后所有接口请求路径都写成 {{baseUrl}}/api/xxx 这种形式。这么做的好处是后续切到测试环境或者换端口只需要改一个变量不需要改每个接口的 URL。我自己已经吃过没配环境变量的亏接口多一点之后改起来非常痛苦。配置环境时还有一个小建议把请求超时时间调大一点。Apifox 默认超时时间是 10 秒本地压测时如果后端连接池被打满很多请求会一直卡在等待连接的阶段超时设置太短会导致误判失败。我通常把超时时间调到 30 秒这样能区分出是请求真的失败还是只是慢。2.3 登录态处理并发场景下不能共用一个 Token黑马点评的登录流程是先调用发送验证码接口拿到 Redis 里的验证码再调用登录接口服务端校验通过后返回 token。后续业务请求都要在请求头里加 authorization值为 token。在 Apifox 里单接口调试时最省事的做法是登录后把 token 复制到环境变量里所有接口共用。但在多并发线程测试里这个问题就复杂了。因为黑马点评的秒杀业务有“一人一单”的限制如果你让 50 个线程全部共用同一个 token等于这 50 个线程在服务端看来全是同一个用户。一个用户抢到券之后后面的请求全部会被判定为“已购买”或者触发重复下单拦截测试结果里会全是业务失败。这不是并发能力的问题是测试数据设计的问题。正确的做法是准备多个手机号提前逐个调登录接口生成多个 token然后在 Apifox 的并发测试里通过数据文件的方式给每个虚拟用户分配不同的 token。具体操作是把几十个手机号对应的 token 整理成一个 JSON 或 CSV 文件在测试场景的数据源配置里引入这个文件接口请求头的 authorization 值改成引用数据字段比如 {{data.token}}。这样每个虚拟用户拿到的都是独立的登录态才能真正测出“多个用户同时抢券”的效果。我准备 token 的过程也很简单写了一段循环调用登录接口的脚本把返回的 token 收集起来输出成文件。手动复制当然也行但多了之后效率太低了建议直接用 Apifox 的测试数据文件功能。3. 核心环节在 Apifox 里搭建并发线程测试场景3.1 创建自动化场景和添加并发步骤打开 Apifox 的“自动化测试”模块新建一个测试场景名字可以叫“黑马点评并发测试”。场景里的每个接口就是一个步骤步骤顺序建议按业务流程来比如先调优惠券查询接口确认数据状态再调秒杀接口最后查订单列表。但这里有一个关键点性能测试不是把每个接口串行执行而是要针对目标接口设置并发让该接口在整个运行周期内被反复并发调用。在 Apifox 的步骤配置中每个接口步骤都有并发相关的设置。以我常用的版本为例运行模式可以配置虚拟用户数、持续时间、线程间延迟、失败停止开关等。不同版本的入口名称可能有差异有的叫“并发配置”有的叫“线程组”但核心参数都是这几个。虚拟用户数代表同时发起请求的线程数持续时间代表测试跑多久线程间延迟代表每个虚拟用户两次请求之间的间隔时间。配置并发测试时有一个容易混淆的地方一个场景里多个接口步骤可以有不同的并发策略。比如登录接口只需要在准备阶段跑几次拿 token不用并发商户查询接口可以用 20 个线程做轻量压测秒杀接口才是主角设置 50 个线程重点观察。Apifox 支持给每个步骤单独配置虚拟用户数这样能模拟更真实的业务混合流量。我建议每个步骤都打开“响应断言”至少检查 HTTP 状态码是 200并且对于关键业务接口再加上 JSON 断言。Apifox 的断言功能有点像 Postman在步骤后置操作里添加断言脚本可以直接用 pm.expect 这种写法也可以选择界面化的断言配置。断言的作用是让压测结果能区分“请求成功”和“业务成功”没有断言的话接口即使返回了业务失败的 JSON也会被统计成成功请求。3.2 多并发线程参数怎么填才合理这里的参数设置是整个测试方案的核心我针对商户查询接口和秒杀接口分别给出了配置。商户查询接口我用了 20 个虚拟用户持续 30 秒线程间延迟为 0 毫秒。选择 20 而不是一开始就上 50是因为商户查询接口走了 Redis 缓存正常情况下响应很快20 个线程已经能产生足够的请求量来观察吞吐曲线。如果 20 线程表现稳定再逐步加到 50 去测试极限。秒杀接口的并发配置是 50 个虚拟用户、持续 30 秒、线程间延迟 0 毫秒、失败停止关闭。为什么是 50因为本地开发机的资源有限50 个并发用户已经足够把 Tomcat 默认线程池和 HikariCP 连接池的压力打出来又不会让整个机器立刻卡死。首次跑测试的人建议从 10 到 20 开始确认脚本没问题再逐步升到 50最后如果想看崩溃点可以上 100。持续时间选 30 秒的理由也很简单时间太短比如只有 5 秒产生的请求样本不足TPS 和错误率数据都没有统计意义时间太长比如 5 分钟秒杀库存早就被消耗完后面所有请求都变成“库存不足”数据同样没有参考价值。线程间延迟为什么选 0 毫秒因为我想压的是“同时涌入”的最坏情况0 延迟可以让所有虚拟用户尽可能密集地发请求把并发问题最大化暴露。如果你更想模拟真实用户操作的平均节奏可以把延迟设置成 100 到 500 毫秒这样趋向于稳定性测试而不是冲击测试。对于首次摸底我建议先用 0 延迟做一次再用 100 毫秒做一次两次数据对比会非常有价值。失败停止开关一定要关掉。如果某个请求因为瞬时网络抖动失败开关开着会导致整个场景提前终止测试数据就废了。正确的做法是允许失败发生最后在报告里看错误率分布。3.3 秒杀接口的专属配置和数据准备秒杀接口的测试比普通查询接口要复杂因为它的前置条件特别多。第一秒杀券必须在数据库里有库存而且 Redis 里的库存预热要和数据库一致。黑马点评的秒杀券库存通常存在 tb_voucher 表的 stock 字段里有些版本还会在 Redis 里维护一个库存 key。跑测试前我习惯先查一下当前库存如果库存已经被上一次测试消耗完就执行一句 UPDATE tb_voucher SET stock 100 WHERE id 1 来重置同时把对应 Redis 库存也重新设置一遍。第二秒杀接口的请求头必须带着独立的 token。这一步在前面已经强调过了实际配置就是在请求头的 authorization 字段里引用数据文件中的变量而不引用环境变量里那个共用的 token。我准备的测试数据文件是一个 CSV包含约 50 组用户手机号和 token正好对应 50 个虚拟用户。第三断言要分成两层。第一层检查 HTTP 状态码是 200这一层判断网络和后端服务是否正常。第二层检查响应体中的 code 字段如果业务返回 code 不等于 1说明这个请求虽然在 HTTP 层面成功了但业务上是失败的——可能是库存不足、已经购买也可能是参数错误。在 Apifox 的统计报告里断言失败会被单独计入失败数这样你就能从失败数里看出是性能问题还是业务限制。这里要提醒一个版本差异问题。如果你用的黑马点评是较新的异步下单版本秒杀接口的流程是先通过 Redis Lua 脚本扣减库存然后把下单消息写入 Redis Stream由消费者线程异步创建订单。这种情况下秒杀接口本身返回成功只代表“库存预扣成功、消息入队成功”并不代表订单一定创建成功。所以压测时除了看 Apifox 的报告还要盯着后端日志看消费者线程有没有报错、Stream 里有没有积压消息。如果是早期的同步下单版本那逻辑会更直接但并发下出现超卖和性能瓶颈的速度反而更快。3.4 断言和数据隔离的正确姿势很多人做压测时忽略断言结果报告里一堆 HTTP 200就以为接口没问题。其实在黑马点评这种业务里HTTP 200 只是最基本的门槛。我建议你在设置并发测试前先单接口调试几次看清楚成功和失败的响应体长什么样然后把断言配置好再开跑。以秒杀接口为例成功时响应体的 code 是 1返回的 data 里有订单 id失败时 code 是 0错误信息可能是“库存不足”或者“请勿重复下单”。我配置断言的方式是先在“后置操作”里写一段 pm 脚本读取响应体中的 code 字段pm.expect(json.code).to.eql(1)这样只要业务失败就会被标记为断言失败。其它接口也一样商户查询接口断言 code 为 1登录接口断言返回数据里包含 token 字段。数据隔离这块除了前面说的多 token 数据文件还有一个很容易被忽略的点订单表的数据污染。秒杀测试每跑一次tb_voucher_order 表就会多出一批订单第二次跑的时候再拿同一批手机号去抢同一张券会被限购拦截。所以我在压测前会写一个重置脚本包含三件事把测试券的库存恢复、把 Redis 里的库存 key 重置、把测试期间生成的订单记录清空。跑一次测试前执行一次这个脚本能保证每次压测都是在干净的数据基础上进行。4. 实测摸底与结果分析4.1 商户查询接口的 20 线程基线测试我先跑商户查询接口作为基线参考。配置是 20 个虚拟用户持续 30 秒线程间延迟 0 毫秒。这个接口没有写操作查询链路简化下来就是请求进来走 Redis 缓存缓存未命中才回源数据库所以整体响应非常快。我这边实测的数据大概是这样30 秒内发送了约 3000 个请求TPS 在 100 左右平均响应时间约 25 毫秒错误率为 0个别请求因为本地机器资源波动的 p99 延迟到了 80 毫秒左右。这个结果说明在 20 并发下商户查询接口本身和底下的 Redis 链路都没有明显瓶颈。不过要注意一个边界如果你的压测请求里带上了让缓存失效的参数或者第一次压测时 Redis 里根本没有缓存数据你会看到一批请求回源数据库响应时间会明显变长。黑马点评的商户查询逻辑里有一个缓存重建的步骤并发下可能出现缓存击穿不过那是另一个话题这次我因为之前已经单独调过接口Redis 里的缓存已经建好了所以数据比较干净。4.2 秒杀接口 50 线程的第一次压测秒杀接口我配置了 50 个虚拟用户、30 秒时长、0 延迟使用准备好的 50 组 token 数据文件。第一次跑完Apifox 报告里显示总请求数约 1200TPS 只有 40 左右平均响应时间达到了 900 毫秒以上错误率接近 10%断言失败率更高。TPS 只有 40 意味着什么意味着 50 个并发用户同时涌入时大量请求被排队等待服务端没有能力快速处理完。配合后端日志看问题非常明显Tomcat 线程池虽然远没打满但数据库连接池先撑不住了。黑马点评默认的 HikariCP 最大连接数是 1050 个并发请求同时来了每个秒杀请求要查库存、扣库存、建订单一顿操作下来几乎把 10 个连接全占住了后面的请求只能等在连接池的队列里等待超时之后就报错。日志里出现了大量类似 connection is not available, request timed out after 30000ms 的异常。除了连接池问题我还看到了一个业务层面的现象断言失败里有一批是“请勿重复下单”。这就验证了我前面的判断如果数据文件没配好50 个线程共用 token 就会这样但这次我用了独立 token为什么还会重复下单查了日志才想起来是因为秒杀接口本身没有做接口幂等快速连续提交的两个请求都通过了校验只是后来事务回滚才挡住了一部分。这其实暴露了黑马点评在并发控制上的一个经典问题后面排查章节我会细说。4.3 调优后重跑连接池参数调整前后对比问题定位到连接池之后我做了几处调整。第一把 HikariCP 的最大连接数从默认的 10 调到 30配置项是 spring.datasource.hikari.maximum-pool-size。第二把 Tomcat 的最大线程数从默认的 200 调到 500配置项是 server.tomcat.threads.max。第三把 Redis 连接池的 max-active 从默认值调大到 50因为秒杀逻辑里查库存、写订单都有 Redis 操作。为什么调成 30 而不是更大我不建议盲目调大。按照 50 个并发用户、每个请求平均耗时 300 毫秒来估算同一时刻大约有 15 到 20 个请求在执行数据库操作30 个连接已经有接近 1.5 倍的余量足够应对响应时间的波动。如果你把连接池调到 200反而会因为数据库服务器资源不足让连接都在等待性能并不会线性提升。调完参数重启项目重新跑同样的 50 线程 30 秒场景结果改善非常明显TPS 从 40 提升到了 130 以上平均响应时间降到约 300 毫秒错误率降到 0断言失败里剩下的基本是“库存不足”和“已购买”这类正常的业务拦截。调优前后的对比表格我列在这里供你参考。指标调优前调优后虚拟用户数5050总请求数约 1200约 3900TPS约 40约 130平均响应时间约 900ms约 300ms错误率约 10%不到 1%主要失败原因连接池超时业务限购/库存不足注意这些数字是本地机器的相对值不代表项目上线后的真实性能但优化前后的趋势是真实的。我只改了两个参数就把吞吐量翻了三倍这正说明了“压测不是测机器跑得有多快而是测配置和代码有没有挡住性能”这句话。5. 踩坑记录与排查心得5.1 所有线程共用 Token 导致大量业务失败这是新手最容易踩的坑。第一次压测时我偷懒直接在环境变量里放了一个 token所有虚拟用户共用。结果秒杀接口的错误率高达 80%报告里全是“请勿重复下单”。一开始我还以为是并发能力问题后来一看后端日志才发现50 个线程全被识别成同一个用户第一波请求抢到券之后后续请求全部被限购拦截。解决方式前面说过就是用数据文件给每个虚拟用户分配独立 token。这里再补充一个细节token 文件里的手机号不要重复因为黑马点评的限购逻辑是按用户 ID 判断的手机号重复等于用户 ID 重复。我自己生成数据文件时直接用了 50 个不同的手机号跑完登录接口后再手动核对了一遍 token 非空。5.2 库存和订单数据污染第二次测试结果失真第一次跑完秒杀我以为可以直接跑第二轮做对比结果库存早就被抢光了所有请求都返回“库存不足”TPS 看着还行但断言失败率 100%数据完全没有价值。这就是测试数据污染。解决办法是写一个重置脚本放在项目目录里每次压测前执行。脚本做的事情很简单把秒杀券的数据库库存 update 回初始值把 Redis 里的库存 key 重新设一遍把本次测试产生的订单记录 delete 掉。如果你用的是异步下单版本还要注意 Redis Stream 里可能残留的未消费消息最好在重置时也清理掉。我实测下来这个脚本能让我一天内反复跑几十轮压测每轮数据都是干净可比的。5.3 后端连接池和线程池不调就跑错误率直线上升黑马点评默认的 HikariCP 最大连接数是 10这对日常开发完全够用但在 50 并发的压测下就是灾难。我在调优前跑的那轮测试里大量请求卡在“等待数据库连接”这个环节最终超时报错。更隐蔽的是Tomcat 的线程池虽说是 200但当连接池耗尽时线程都阻塞在获取连接上线程池也很快被占满新请求直接排队。调参时要记住一个原则参数是配合业务场景的不是越大越好。连接池开太大数据库端并发上去后反而造成大量上下文切换线程池开太大内存占用增加GC 压力也上来。我在这次项目里选择 30 连接 500 线程是针对“单机本地 50 并发”这个场景的合理值。如果你的机器配置更高或者秒杀逻辑更简单可以自行调整。5.4 Apifox 做并发测试的边界和正确姿势用完整套流程后我对 Apifox 在并发测试上的定位有了更清晰的判断。它适合做中小规模的接口并发验证和自动化回归尤其是几十个虚拟用户这个量级配置方便、报告直观、能和接口调试无缝衔接。但如果你是做生产环境的容量评估、要精确控制压测曲线、要看更细粒度的服务器监控那还是用 JMeter 配合 Grafana 这类专业方案更合适。还有一个容易被忽略的问题Apifox 的压测机本身也是瓶颈。如果你在同一台笔记本上既跑项目、又跑 Apifox、还开着浏览器和录屏软件测试结果会掺入大量本地资源竞争的噪声。我建议跑压测时把能关的程序都关掉至少在报告里注明测试环境的资源状况否则数据没法横向对比。最后再分享一点个人体会这轮测试做完我最深的感受是压力测试的价值不在于得到一个漂亮的 TPS 数字而在于它逼着你去思考每个接口背后的依赖关系。黑马点评的秒杀接口看起来只是一个 POST 请求但它背后连着 Redis、MySQL、连接池、事务、限购规则任何一个环节出问题最终都会在并发场景里以错误率飙升的形式暴露出来。这次压测给我的收获除了数据更重要的是建立了“压测前先设计数据、压测中盯日志、压测后清理环境”这套操作习惯。最后再分享一个小技巧测试前把重置环境的 SQL 和 Redis 命令写成脚本命名成 reset.sh 或者放到测试文档里每次跑测试前执行一次。看起来是很小的一步但能让你在反复调参优化的过程中节省大量重复劳动也能保证每一轮测试的数据都是可比的。如果你正准备拿黑马点评去面试可以把 Apifox 生成的测试报告和优化前后的对比数据整理到项目介绍里一句“我用 Apifox 做了 50 线程的并发压测定位并调整了连接池参数将 TPS 从 40 提升到 130”比单纯说“我做了秒杀功能”要有说服力得多。
