压测数据准备

一、为什么压测前必须准备数据

很多压测失败，真正的问题不在工具，也不在代码，而在数据。

例如：

• 账号不够用
• 商品库存不够
• 订单号被重复消费
• 所有线程都打到同一条数据

这类问题会导致：

• 大量失败请求
• 压测结果失真
• 根本无法判断真实瓶颈

所以：

压测数据准备，是压测成功的基础设施，不是可有可无的前置工作。

二、压测数据通常包括什么

常见压测数据主要有：

• 用户账号
• 商品数据
• 库存数据
• 订单数据
• 支付数据
• 唯一请求 ID

不同系统重点不同，但原则一致：

• 数据要真实可用
• 数据量要足够
• 数据之间要能关联

三、账号数据怎么准备

如果压测流程里有登录，就一定要先准备足够的账号。

例如：

1000 并发
每个线程一个账号

那你至少要准备：

1000 个可登录账号

更稳妥的做法是多准备一部分冗余账号。

推荐原则

• 不同线程尽量使用不同账号
• 账号状态要统一
• 避免一个账号被多个线程重复抢占

四、商品和库存数据怎么准备

电商、秒杀、下单类压测最容易踩的坑就是库存。

例如：

只有一个商品
库存只有 100
但你要压 1000 个并发下单

这样压测结果一定失真，因为后面大量请求都只是“库存不足”。

推荐做法

• 准备多个商品
• 每个商品准备足够库存
• 不同线程尽量打散到不同商品

五、订单和支付数据要注意什么

订单类数据通常有两个特点：

• 唯一性
• 不可重复消费

例如：

• 一个订单不能被重复支付
• 一个订单号不能重复提交

所以压测中要避免：

多个线程使用同一个 orderId

推荐做法

• 每次动态创建订单
• 使用唯一 ID
• 必要时在压测后清理订单数据

六、为什么测试数据量必须足够

如果数据量不够，JMeter 虽然还能跑，但结果会越来越假。

例如：

CSV 里只有 100 个用户
压测线程是 1000

后果通常是：

• 数据被重复读取
• 登录状态互相覆盖
• 接口冲突增加

因此要遵循一个简单原则：

数据量至少覆盖你的有效并发规模。

七、如何避免数据冲突

压测中的冲突通常来自三个方面：

1. 同一账号被重复使用

解决：

• 账号池足够大

2. 同一业务对象被重复操作

例如同一个商品、同一个订单。

解决：

• 数据分片
• 随机打散

3. 唯一键重复

例如 requestId、订单号、支付流水号。

解决：

• UUID
• 时间戳
• 自增序列

八、数据隔离很重要

压测最好不要直接污染共享测试环境。

推荐做法：

• 使用压测专用账号
• 使用压测专用商品
• 使用压测专用库表前缀或标记
• 压测后统一清理

这样做的好处是：

• 不影响其他团队
• 出问题更容易回滚
• 数据分析更方便

九、一个简单的准备清单

你可以按这个清单准备：

账号

• 是否足够
• 是否可登录
• 是否状态一致

商品

• 是否足够多
• 是否库存足够
• 是否允许重复购买

订单

• 是否需要预生成
• 是否允许重复消费

其他

• token 是否动态获取
• requestId 是否唯一
• 是否需要压测后清理数据

十、Java 后端工程师的关注点

作为 Java 后端开发，你做数据准备时要特别看：

• 数据库唯一索引是否会冲突
• Redis key 是否会热点集中
• 消息幂等逻辑是否会被重复触发
• 下游系统是否允许重复调用

因为这些点经常直接决定压测结果到底有没有参考价值。

十一、总结

压测数据准备的核心不是“多造点数据”，而是：

• 数据足够
• 数据真实
• 数据隔离
• 数据可重复使用

如果数据没准备好，压测再怎么跑，结果也不可信。