实战：利用脚本批量生成用户Token，驱动JMeter完成高并发秒杀场景压测

1. 场景需求与技术选型

电商平台在促销活动前必须对核心接口进行充分压测，尤其是秒杀这类高并发场景。以黑马点评项目为例，我们需要模拟1000个真实用户同时抢购限量100件商品的极端情况。传统手动造数据的方式效率低下，而直接使用重复Token会导致测试失真。

我推荐的技术组合方案是：

• 数据生成层：用Java编写批量登录脚本，自动获取真实用户Token
• 压测执行层：JMeter作为行业标准压测工具
• 数据桥梁：CSV文件存储Token供JMeter参数化调用

这套方案的优点在于：

1. 真实模拟用户会话（每个请求携带独立Token）
2. 避免测试账号被风控拦截
3. 支持快速扩展测试规模（万级用户只需修改循环次数）

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");
    }
}

注意几个关键点：

1. 请求头需设置Content-Type: application/json
2. 登录接口返回格式需与项目实际保持一致
3. 建议添加异常处理和日志输出

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 基础线程组设置

1. 创建线程组：

   • 线程数：1000（模拟用户数）
   • Ramp-up时间：建议30秒（逐步加压）
   • 循环次数：根据测试需求设置

2. 添加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 监听器与断言

必备监听器：

1. 聚合报告：查看TPS、响应时间等核心指标
2. 响应时间图：观察性能曲线变化
3. 断言结果：添加响应断言，验证接口返回码

建议的响应断言设置：

• 响应字段：HTTP响应代码
• 模式匹配规则：等于
• 测试模式：200

4. 压测结果分析

4.1 关键指标解读

典型聚合报告包含：

• Throughput：系统吞吐量（TPS）
• Average：平均响应时间
• 90% Line：90%请求的响应时间
• Error %：错误率

健康系统的表现：

• 错误率低于0.1%
• 平均响应时间<500ms
• TPS曲线平稳无剧烈波动

4.2 常见问题排查

根据我的经验，这些问题最常见：

1. Token失效：检查Redis过期时间设置
2. 数据库连接池耗尽：监控Druid等连接池状态
3. 服务雪崩：添加熔断机制和限流策略

推荐添加的监控项：

• JVM内存使用率
• MySQL活跃连接数
• Redis QPS

5. 进阶技巧与优化

5.1 分布式压测

当单机JMeter无法满足压力时：

1. 部署多台JMeter Slave节点
2. 修改jmeter.properties中的远程配置
3. 使用主节点统一触发

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 参数化增强

更真实的压测需要：

1. 商品ID参数化（模拟不同商品秒杀）
2. 请求时间随机化（避免完全同步请求）
3. 用户行为多样化（加入浏览、加购等操作）

实现示例：

plaintext复制JMeter变量表达式：
- ${__Random(1,100)}  # 随机商品ID
- ${__RandomString(10)}  # 随机字符串
- ${__timeShift(yyyy-MM-dd HH:mm:ss,,,)}  # 时间戳

5.3 持续集成方案

将压测纳入CI/CD流程：

1. 使用Jenkins定时触发测试任务
2. 通过JMeter ANT插件生成HTML报告
3. 设置性能阈值自动告警

典型Jenkinsfile片段：

groovy复制stage('Performance Test') {
    steps {
        bat 'jmeter -n -t test.jmx -l result.jtl'
        perfReport sourceDataFiles: 'result.jtl'
    }
}

在实际项目中使用这套方案后，我们成功将秒杀接口的吞吐量从500TPS提升到3000TPS。关键点在于持续优化数据库索引和引入Redis集群分担压力。建议每次压测后保留完整测试报告，方便后续做对比分析。