测试数据报告/Day7

关于我简历内数据吞吐量“2-3”倍怎么来的这回事

一、测试目标

• 验证本项目秒杀接口在“异步链路（Kafka）”与“同步链路（直落库）”下的性能差异。
• 在可接受延迟目标下评估可用吞吐量。
• 本轮最终对比口径采用：HTTP p95 < 300ms。

二、测试对象

• 接口：POST /voucher-order/seckill/{id}
• 券ID：voucher_id=1
• 压测脚本：k6_seckill_ab.js

三、测试环境

• 时间：2026-03-18（本地）
• 后端：hmdp-core-service 本地 java -jar 启动，端口 8085
• 中间件：Docker 启动 MySQL(3306) / Redis(6379) / Kafka(9092)
• 压测工具：k6 v1.6.1
• 数据准备：
  • 秒杀券库存调到 200000
  • 活动时间窗口设为当前有效
  • 清理秒杀相关 Redis key，避免旧缓存干扰

四、测试流程

1. 启动中间件与后端，校验 actuator/health=UP。
2. 调整券库存、时间窗口并清缓存。
3. 冒烟验证：发验证码 -> 登录 -> 下单 成功。
4. 跑异步链路压测。
5. 为保证“同步 vs 异步”同代码可比，加了链路开关并切到同步链路压测。
6. 逐档调整 VUS，找到 p95 < 300ms 的可用上限。

五、关键实现与参数说明

• 新增链路开关：seckill.order.mode=sync|async
  文件：VoucherOrderServiceImpl.java
• 压测过程使用了临时运行参数（未改配置文件）：
  • -Dseckill.access.token.enabled=false
  • -Drate-limit.*=100000（放开限流，避免入口限流掩盖链路能力）
• 脚本使用 per-vu-iterations，每个虚拟用户下单 1 次。

六、测试规模

• 异步链路测试档位：VUS=100/250/280/320
• 同步链路测试档位：VUS=30/40/45/50/100

七、结果展示

异步链路（Kafka）：

• VUS=280：http_req_duration p95=297.8ms，biz_success_total=280，biz_success_rate≈132.37/s
• VUS=320：p95=355.19ms（超 300ms）

同步链路（直落库）：

• VUS=45：http_req_duration p95=249.62ms，biz_success_total=45，biz_success_rate≈58.84/s
• VUS=50：p95=415.64ms（明显超 300ms）

按 p95 < 300ms 的可用点对比：

• 异步可用上限约 VUS=280
• 同步可用上限约 VUS=45
• 并发承载比：280 / 45 ≈ 6.2x
• 成功业务速率比（k6 biz_success_total 速率）：132.37 / 58.84 ≈ 2.25x（2-3倍）

八、结论

• 在本次同环境、同接口、同数据规模下，异步链路显著优于同步链路。
• 若以 p95 < 300ms 作为准入标准：
  • 异步链路可用吞吐明显更高，业务成功速率约为同步的 2.25x。
  • 并发可承载上限约为同步的 6.2x。

九、产物文件

• 脚本：k6_seckill_ab.js
• 关键结果：

十、备注

• 当前压测是“下单链路”能力评估，不包含完整支付回调闭环吞吐。