小红帽的灰灰狼1. 场景需求与技术选型
电商平台在促销活动前必须对核心接口进行充分压测，尤其是秒杀这类高并发场景。以黑马点评项目为例，我们需要模拟1000个真实用户同时抢购限量100件商品的极端情况。传统手动造数据的方式效率低下，而直接使用重复Token会导致测试失真。
我推荐的技术组合方案是：
- 数据生成层：用Java编写批量登录脚本，自动获取真实用户Token
- 压测执行层：JMeter作为行业标准压测工具
- 数据桥梁：CSV文件存储Token供JMeter参数化调用
这套方案的优点在于：
- 真实模拟用户会话（每个请求携带独立Token）
- 避免测试账号被风控拦截
- 支持快速扩展测试规模（万级用户只需修改循环次数）
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 批量获取用户Token实战
2.1 用户数据准备
首先确保数据库中有足够测试用户，推荐使用批量插入SQL：
sql复制INSERT INTO tb_user (phone, password)
VALUES
('13800000001', 'e10adc3949ba59abbe56e057f20f883e'),
('13800000002', 'e10adc3949ba59abbe56e057f20f883e')
-- 继续补充直到1000条...
密码字段存储的是MD5加密后的"123456"，方便统一测试。实际项目中建议使用更复杂的密码策略。
2.2 Java批量登录脚本开发
核心代码结构如下：
java复制@SpringBootTest
public class TokenGenerator {
@Autowired
private IUserService userService;
@Test
void generateTokens() throws Exception {
List<User> users = userService.list();
BufferedWriter writer = new BufferedWriter(new FileWriter("tokens.txt"));
for(User user : users) {
String token = loginAndGetToken(user.getPhone());
writer.write(token);
writer.newLine();
}
writer.close();
}
private String loginAndGetToken(String phone) {
// 构建JSON请求体
JSONObject json = new JSONObject();
json.put("phone", phone);
// 发送HTTP请求
HttpPost post = new HttpPost("http://localhost:8080/api/user/login");
post.setEntity(new StringEntity(json.toString(), ContentType.APPLICATION_JSON));
// 处理响应
HttpResponse response = httpClient.execute(post);
String responseBody = EntityUtils.toString(response.getEntity());
return new JSONObject(responseBody).getString("data");
}
}
注意几个关键点：
- 请求头需设置
Content-Type: application/json - 登录接口返回格式需与项目实际保持一致
- 建议添加异常处理和日志输出
2.3 脚本优化技巧
在实际项目中，我遇到过这些坑：
- 网络抖动问题：添加重试机制，建议最多3次重试
- 性能瓶颈：改用HttpClient连接池，显著提升请求速度
- 结果验证：对生成的token做二次校验，确保有效性
优化后的核心代码片段：
java复制// 使用连接池
PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
cm.setMaxTotal(200); // 最大连接数
cm.setDefaultMaxPerRoute(20); // 每个路由最大连接数
CloseableHttpClient httpClient = HttpClients.custom().setConnectionManager(cm).build();
// 带重试的请求执行
HttpResponse response = Retry.execute(3, () -> httpClient.execute(post));
3. JMeter压测配置
3.1 基础线程组设置
-
创建线程组：
- 线程数：1000（模拟用户数）
- Ramp-up时间：建议30秒（逐步加压）
- 循环次数：根据测试需求设置
-
添加CSV Data Set Config：
- Filename：指向生成的tokens.txt
- Variable Names：填token（后续用${token}引用）
- Recycle on EOF?：True（循环使用token）
3.2 HTTP请求配置
秒杀接口的关键配置：
plaintext复制HTTP Request:
- Method: POST
- Path: /api/seckill/order
- Body Data: {"goodsId": 1} # 测试商品ID
HTTP Header Manager:
- Authorization: ${token}
- Content-Type: application/json
3.3 监听器与断言
必备监听器：
- 聚合报告：查看TPS、响应时间等核心指标
- 响应时间图：观察性能曲线变化
- 断言结果：添加响应断言，验证接口返回码
建议的响应断言设置：
- 响应字段：HTTP响应代码
- 模式匹配规则：等于
- 测试模式：200
4. 压测结果分析
4.1 关键指标解读
典型聚合报告包含：
- Throughput：系统吞吐量（TPS）
- Average：平均响应时间
- 90% Line：90%请求的响应时间
- Error %：错误率
健康系统的表现：
- 错误率低于0.1%
- 平均响应时间<500ms
- TPS曲线平稳无剧烈波动
4.2 常见问题排查
根据我的经验，这些问题最常见：
- Token失效：检查Redis过期时间设置
- 数据库连接池耗尽：监控Druid等连接池状态
- 服务雪崩：添加熔断机制和限流策略
推荐添加的监控项：
- JVM内存使用率
- MySQL活跃连接数
- Redis QPS
5. 进阶技巧与优化
5.1 分布式压测
当单机JMeter无法满足压力时：
- 部署多台JMeter Slave节点
- 修改jmeter.properties中的远程配置
- 使用主节点统一触发
properties复制# Slave节点配置
server.rmi.ssl.disable=true
server_port=1099
# Master节点配置
remote_hosts=192.168.1.101:1099,192.168.1.102:1099
5.2 参数化增强
更真实的压测需要：
- 商品ID参数化（模拟不同商品秒杀）
- 请求时间随机化（避免完全同步请求）
- 用户行为多样化（加入浏览、加购等操作）
实现示例：
plaintext复制JMeter变量表达式：
- ${__Random(1,100)} # 随机商品ID
- ${__RandomString(10)} # 随机字符串
- ${__timeShift(yyyy-MM-dd HH:mm:ss,,,)} # 时间戳
5.3 持续集成方案
将压测纳入CI/CD流程：
- 使用Jenkins定时触发测试任务
- 通过JMeter ANT插件生成HTML报告
- 设置性能阈值自动告警
典型Jenkinsfile片段：
groovy复制stage('Performance Test') {
steps {
bat 'jmeter -n -t test.jmx -l result.jtl'
perfReport sourceDataFiles: 'result.jtl'
}
}
在实际项目中使用这套方案后，我们成功将秒杀接口的吞吐量从500TPS提升到3000TPS。关键点在于持续优化数据库索引和引入Redis集群分担压力。建议每次压测后保留完整测试报告，方便后续做对比分析。