JMeter压测IBM MQ：高吞吐量场景下如何生成唯一请求数据？

以下是几种能确保请求唯一性且适配高吞吐量需求的方案：

1. 线程ID+毫秒时间戳+随机数组合 #

利用线程ID的唯一性、毫秒时间戳的时序性，再补充小范围随机数，几乎可以避免碰撞。在JSR223 PreProcessor中使用以下代码：

long threadId = ctx.getThreadNum();
long timestamp = System.currentTimeMillis();
int random = ThreadLocalRandom.current().nextInt(1000);
String uniqueKey = String.format("%d_%d_%d", threadId, timestamp, random);
vars.put("uniqueKey", uniqueKey);

ThreadLocalRandom比普通Random更适合多线程场景，线程安全且性能更高。

2. 完整UUID生成 #

之前截断UUID到30位的操作会丢失部分唯一性，直接使用JMeter原生的__UUID函数生成完整唯一值：

• 带横杠格式：${__UUID}
• 不带横杠格式：${__UUID(false)}
  UUID的128位结构决定了其重复概率可以忽略不计，完全适配高并发场景。

3. 线程独立计数器+线程ID #

使用JMeter的计数器元件，配置如下：

• 变量名：counter
• 起始值：1
• 递增：1
• 最大值：设置为测试总请求数的2倍以上（比如10000）
• 勾选“每个线程组独立计数”
  然后将唯一标识设置为${__threadNum}_${counter}，每个线程的计数器独立递增，结合线程ID后全局唯一，完全不会重复。

4. 预生成CSV唯一值池 #

提前生成足够多的唯一数据（比如测试总请求数的1.5倍）保存到CSV文件，用CSV Data Set Config读取：

• 文件名：选择你的CSV文件路径
• 变量名：uniqueValue
• 线程共享模式：所有线程
• 勾选“每次迭代下一行”
• 取消勾选“遇到文件结束符停止线程”（可选，若数据足够多可不设）
  这种方式性能极高，读取文件的开销远低于实时生成唯一值，适合超高性能需求的场景。

5. 全局原子计数器 #

利用JMeter全局属性结合AtomicInteger实现线程安全的全局递增计数器，确保每个请求拿到唯一的递增数值。在JSR223 PreProcessor中使用：

if (!props.containsKey("globalCounter")) {
    props.put("globalCounter", new java.util.concurrent.atomic.AtomicInteger(1));
}
java.util.concurrent.atomic.AtomicInteger counter = props.get("globalCounter");
String uniqueValue = "req_" + counter.getAndIncrement();
vars.put("uniqueValue", uniqueValue);

AtomicInteger的原子操作保证了多线程下递增不会出现重复，适合需要全局唯一序号的场景。

排查之前方案失效的可能原因 #

• __RandomString(6,...)：6位字符集的组合数虽多，但如果Pod端的唯一校验逻辑只取部分字段，可能导致重复；
• __timeShift(yyMMddHHmm,...)：精度到分钟，同一分钟内的请求会拿到相同值，必然重复；
• 随机变量（Per Thread=true）：不同线程可能生成相同随机数，导致全局重复。

建议先添加Debug Sampler查看每个请求的变量值，确认是生成逻辑问题还是Pod端校验逻辑问题。

内容的提问来源于stack exchange，提问作者Sachin Patel