简介面向需要验证RabbitMQ高并发性能的开发测试人员这份资源给出了基于JMeter 3.3的完整配套方案。作者在实战中整合了AMQP相关依赖与脚本解决了原生JMeter不支持消息队列压测的问题适合正在搭建RabbitMQ压测环境或想快速上手AMQP Sampler的读者。压缩包共2000个文件约51.92MB包含1510个html页面/说明文档、482张png示意图、271个js脚本、82个jar依赖包以及45个jmx测试计划文件结构完整便于按目录查阅。已有1091人浏览学习。从中可以获取JMeter与RabbitMQ集成所需的jar包、AMQP连接参数配置示例、基于线程组和监听器的压测脚本模板以及验证吞吐量、响应时间和错误率时的常见排错思路对搭建消息队列性能测试平台有直接参考价值。1. JMeter 3.3 追加 RabbitMQ 压测从零搭出一套百万级消息压测台用 JMeter 3.3 对一个 RabbitMQ 集群做压测乍看是件“加个 JMS 采样器就能开跑”的事实际上两个大坑叠在一起JMeter 3.3 内置的采样器只认 JMS 规范而 RabbitMQ 走的是 AMQP 0-9-1老版本 JMeter 的 Groovy 引擎又停留在 2.4.x网上抄来的新语法脚本一跑就翻车。这份“jmeter3.3 工具 rabbitmq 压测”资源本质是一套把 AMQP 客户端、采样器脚本、JMX 压测骨架和参数化模板打包好的工程解决的是“从零配环境”到“跑出可信吞吐数据”之间的所有琐碎环节。适合要做生产者压测、消费者压测、队列容量评估和消费堆积验证的从业者也适合刚接手 JMeter 3.3 老环境但不想升级的团队。2. 环境与选型为什么是 AMQP 插件而不是 JMeter 自带采样器2.1 JMeter 3.3 的采样器能力边界JMeter 自带的 JMS Point-to-Point 和 JMS Publisher 采样器面向的是标准 JMS 接口。RabbitMQ 虽然可以用 Qpid JMS 客户端勉强桥接但要在 JMeter 里配 JNDI、配连接工厂、配 destination任何一个环节的名字写错脚本能跑但数据全是“连不上队列”的报错定位成本极高而且 JMS 桥接层会在高并发下暴露连接抖动问题你一压测就发现大量 JMSException根本分不清是 Broker 扛不住还是桥接层在捣乱。AMQP 插件直接建立 Connection 和 Channel绕开 JNDI 这一层黑匣子参数全部平铺在配置界面或者脚本里。对做压测的人来说有个直观的好处你能清楚看到当前采样器到底在连哪个 vHost、走哪条 routingKey、用的是 direct 还是 topic 交换机出问题时能在五分钟内定位到是网络、账号、权限还是交换机配置的问题。RabbitMQ 原生协议是 AMQP 0-9-1插件走原生协议意味着你压出来的连接数、通道数、消息吞吐与生产环境基本一致不会被中间适配层稀释。选 AMQP 插件而不是 JMS 桥接还有一个性能上的考量。JMS 桥接每次采样要经过 JMS 客户端的 session、producer、message 转换多一层对象转换和编解码开销在单线程单通道模式下差距不显一旦线程数拉到五十以上桥接层的 CPU 消耗会先于 Broker 到达瓶颈压出来的曲线没参考价值。AMQP 插件的 ConnectionFactory 直连 5672 端口链路短吞吐曲线才真实。工具包默认采用“自研或第三方 AMQP 采样器 amqp-client 5.x 依赖”的组合JMeter 3.3 的 lib 里补上这两个 jar 就能跑。2.2 把 AMQP 客户端与采样器装进 JMeter 3.3这套工具包内的目录结构跟标准的 apache-jmeter-3.3 解压目录对比差别集中在两个目录上lib/ext 下多出 AMQP 采样器插件 jarlib 下多出 amqp-client 5.x 及其依赖的 slf4j-api、slf4j-simple。安装退款其实就是“解压、放 jar、配 JDK、起 JMeter”四步但每一步都有细节。# 工具包内 JMeter 3.3 的目录结构关键部分 apache-jmeter-3.3/ ├── bin/ │ ├── jmeter.bat │ ├── jmeter.sh │ └── jmeter.properties ├── lib/ │ ├── amqp-client-5.x.jar │ ├── slf4j-api-1.7.x.jar │ └── slf4j-simple-1.7.x.jar └── lib/ext/ ├── jmeter-amqp-sampler.jar └── jmeter-plugins-*.jaramqp-client 5.x 必须放在 lib 目录而不是 lib/ext因为采样器插件依赖它JMeter 的类加载顺序里 lib/ext 插件优先但第三方依赖要从 lib 主类路径里找。如果只把 amqp-client 丢进 lib/ext启动时通常不报错一执行采样器就抛 NoClassDefFoundError这种问题最容易让人误判是脚本写错了。环境变量这一步要特别注意JMeter 3.3 官方支持的最高 JDK 版本是 JDK 8不要让 JAVA_HOME 指向 JDK 9 或更高。3.3 内置的 Groovy 是 2.4.x对 JDK 9 以上的模块化支持不完整界面本身能启动但执行 JSR223 采样器时会出现奇怪的安全异常或类转换错误。工具包内如果带了 .bat / .sh 启动脚本脚本里会把 JAVA_HOME 固定到 jdk8 路径这是踩过坑之后留下的配置。# 工具包内的 jmeter 启动脚本中建议保留的 JVM 参数 export JAVA_HOME/path/to/jdk8 export JVM_ARGS-Xms1G -Xmx2G -XX:UseG1GC $JAVA_HOME/bin/java $JVM_ARGS -jar $JMETER_HOME/bin/ApacheJMeter.jarJVM 堆大小给到 1G 到 2G 是 JMeter 压 RabbitMQ 的最低建议。压测过程中监听器会缓存大量采样结果如果堆太小抽样数据一多就频繁 Full GC压测脚本线程会被 STW 暂停打断Tps 曲线出现规律的锯齿数据没法用。另外消息体较大的场景比如每条消息几十 KB字符串拼接会占大量堆内存建议按照峰值消息大小和并发线程数反推堆上限一百线程每条 50KB 时2G 堆是底线。2.3 最小可用 JMX线程组、采样器、监听器的骨架工具包内附带一个最小可用的 .jmx 压测骨架文件它不复杂但组件配置的方向对了新手照着自己重新搭也不会跑偏。骨架结构本质上只有“线程组 采样器 监听器”三层新建测试计划后第 1 步添加线程组配置线程数、Ramp-Up 时间和循环次数。线程数等于模拟的生产者或消费者数量Ramp-Up 时间建议设成线程数除以期望的每秒启动数比如 100 线程想每秒启动 20 个Ramp-Up 就填 5 秒避免瞬时连接风暴打到 RabbitMQ 的端口上。第 2 步添加用户自定义变量把 RMQ_HOST、RMQ_PORT、RMQ_VHOST、RMQ_USER、RMQ_PASS、RMQ_EXCHANGE、RMQ_ROUTING_KEY 全部放到变量里这样从测试环境切换到预发环境不需要改脚本只改变量。第 3 步添加 JSR223 Sampler 或 Java Request Sampler语言选 Groovy采样逻辑写在脚本区。第 4 步添加断言建议用 JSR223 断言或响应断言配合。第 5 步添加聚合报告监听器和 Simple Data Writer后者用于把结果追加写入 JTL 文件方便压测结束后再做数据对账。表格最小 JMX 骨架的组件与配置JMeter 组件关键配置用途Thread Group线程数目标并发Ramp-Up5~10s定义压测并发模型User Defined VariablesRMQ_HOST、RMQ_VHOST、RMQ_EXCHANGE 等参数集中管理避免硬编码JSR223 Sampler语言选 Groovy脚本内用 props 复用 Connection执行发布或消费逻辑JSR223 Assertion判定 channel 是否 open、发布是否确认过滤无效样本避免虚高 TPSSimple Data Writer输出格式指定为 CSV存 JTL 文件保留原始样本供离线分析Aggregate Report关注吞吐量、平均响应时间、异常率直观掌握本次压测结果JSR223 采样器里有一个容易被忽略的细节脚本引擎默认按名称缓存但如果你选了语言为 Groovy采样器内部每次迭代会检查脚本是否变化没变化就复用编译后的脚本实例。这个特性下vars.get、props.get这类绑定变量访问是每次迭代时重新注入的而通过props.put存进去的 Connection 对象能横跨多线程共享。骨架脚本里故意把 Connection 建在 setUpt 线程组而不是普通线程组就是为了让所有压测线程共用同一个长连接后面第三章会拆开讲。3. 生产者压测落地连接复用与发布确认参数3.1 Connection 与 Channel 的复用模型RabbitMQ 的 Java 客户端里Connection 是长连接负责维护与 Broker 的 TCP 链路、心跳和异常恢复Channel 是建立在 Connection 之上的轻量会话每条信道独立编号负责具体的 declare、publish、consume 操作。一个压测线程组里有 N 个线程如果每个线程都新建一个 ConnectionRabbitMQ 服务端的文件描述符很快被打爆现象就是连上之后几秒就被服务端重置日志里疯狂刷“accepting new connections”和“closing connection (connection forced)”。正确做法是一个压测进程只创建少量 Connection比如 1 到 2 个所有压测线程从连接池复用同一个 Connection每个线程在迭代开始时动态创建 Channel。Channel 创建成本极低服务端对单条连接上的 Channel 数量默认上限是 2047一百个压测线程各占一个 Channel 完全没压力。复用模型同时降低了 TLS 握手的开销——如果 RabbitMQ 开了 5671 端口走 AMQP over TLS每次建 Connection 都要走一次完整 TLS 握手压测还没跑到吞吐量先被握手延迟淹没了。还一个重要参数是自动恢复。很多人在压测中遇到网络抖动下意识会打开factory.setAutomaticRecoveryEnabled(true)希望客户端自动重连。压测时这个选项要关掉因为自动恢复机制会掩盖短暂故障把所有连接瞬间重建导致 Broker 端出现极高的连接建立速率生产环境未必会有这种表现。工具包脚本里强制setAutomaticRecoveryEnabled(false)就是不想让恢复逻辑干扰压测数据。3.2 用 JSR223 Sampler 写一个带发布确认的生产者脚本下面这段脚本是工具包内生产者压测的核心逻辑放在 JSR223 Sampler 的 Script 区语言选 Groovyimport com.rabbitmq.client.ConnectionFactory import com.rabbitmq.client.Connection import com.rabbitmq.client.Channel import com.rabbitmq.client.MessageProperties String host props.get(RMQ_HOST) int port Integer.parseInt(props.get(RMQ_PORT)) String vHost props.get(RMQ_VHOST) String user props.get(RMQ_USER) String pass props.get(RMQ_PASS) String exchange props.get(RMQ_EXCHANGE) String routingKey props.get(RMQ_ROUTING_KEY) // 从 props 缓存里拿 Connection首次迭代时才真正创建 Connection conn props.get(rmq.conn) if (conn null || !conn.isOpen()) { ConnectionFactory factory new ConnectionFactory() factory.setHost(host) factory.setPort(port) factory.setVirtualHost(vHost) factory.setUsername(user) factory.setPassword(pass) factory.setConnectionTimeout(500) factory.setHandshakeTimeout(5000) factory.setRequestedHeartbeat(5) factory.setAutomaticRecoveryEnabled(false) conn factory.newConnection() props.put(rmq.conn, conn) } Channel ch conn.createChannel() ch.confirmSelect() // 构造消息体序号 发送端时间戳 可变长度数据 String seqNo vars.get(SEQ_NO) String sampleData vars.get(SAMPLE_DATA) String payload {\seq\: seqNo ,\ts\: System.currentTimeMillis() ,\data\:\ sampleData \} ch.basicPublish(exchange, routingKey, MessageProperties.PERSISTENT_TEXT_PLAIN, payload.getBytes(UTF-8)) // 等待单条发布确认超时或失败时标记样本失败 if (ch.waitForConfirms(1000)) { long nextSeq Long.parseLong(seqNo) 1 vars.put(SEQ_NO, String.valueOf(nextSeq)) prev.setResponseMessage(seq seqNo confirmed) } else { prev.setSuccessful(false) prev.setResponseMessage(publish confirm timeout) } ch.close()这段脚本的逻辑分四层。第一层是 Connection 的懒加载首次迭代时创建并放入 props 缓存后续线程直接复用不会重复建连接第二层是 Channel 的按次创建每次迭代从已开的连接上取一个信道用完后关闭把信道生命周期压到单次采样范围内第三层是消息体构造注意seq从 JMeter 变量里自增ts取发送端毫秒时间戳这是后面做延迟分桶和对账的数据基础第四层是发布确认confirmSelect 打开确认机制waitForConfirms 同步等待 Broker 返回 ack。核心参数层面setConnectionTimeout(500)控制 TCP 建连超时压测中 Broker 不可达时能快速失败而不是让线程挂死setHandshakeTimeout(5000)控制 AMQP 握手超时网络波动时避免线程堆积setRequestedHeartbeat(5)让客户端每 5 秒发一次心跳Broker 能及时发现死连接。MessageProperties.PERSISTENT_TEXT_PLAIN标记消息为持久化消息会落盘这是压测生产链路的标准配置如果不落盘Broker 内存队列的吞吐会比持久化模式高一截和生产环境数据对不上。waitForConfirms(1000)是同步阻塞调用QPS 要求低时每条消息确认一次最稳妥高吞吐压测时单条确认会成为性能瓶颈需要改成每 N 条批量确认。3.3 消息体构造与顺序参数化消息体构造是压测可信度的分水岭。很多新手压测时 body 写死一条固定字符串跑出来的 Tps 只代表“空消息的极限”一旦切到真实业务消息Broker 的扇出、路由、落盘开销完全不同。工具包推荐用 CSV Data Set Config 做业务字段参数化压测数据文件里每行是一个业务样本JMeter 每次迭代按顺序取一行字段通过${field}引用拼接进 payload。这种做法配合 JMeter 的 CSV 配置能做到数据不重样避免 RabbitMQ 对重复消息的某些优化干扰结果。如果压测目标是压满 Broker 而不是模拟业务就用SAMPLE_DATA变量控制消息体长度。脚本中用字符串乘法生成指定大小的填充数据int msgSize Integer.parseInt(vars.get(MSG_SIZE)) String sampleData x * msgSize vars.put(SAMPLE_DATA, sampleData)消息体大小影响的是网络带宽和磁盘 IO直接影响 Broker 的持久化耗时。建议按 1KB、4KB、16KB、64KB 四档分别跑一轮每个档位单独记录 Tps 和延迟这样能画出“消息大小-吞吐”曲线定位到 Broker 的吞吐拐点。压测时消息体大小固定在一个值跑出来的数据只代表该消息大小的能力这是第一个要记住的边界条件。另一个关键细节是时间戳的放置位置。消息体内放发送端毫秒时间戳消费端拿到消息后做差值能得到端到端延迟如果你只放消费端时间那只能知道“消费处理耗时”无法知道消息在队列里蹲了多久。延迟压测必备发送时间戳这也是第三章脚本里ts字段的用途所在。4. 消费者压测落地吞吐指标与堆积判定4.1 消费采样器与 ack 模式的选择消费者压测有两种实现路径basicGet 轮询和 Consumer 回调。压测场景里我通常用 basicGet 轮询因为它在 JMeter 线程模型下可控性最好——每次采样执行一次取消息操作取到了就处理取不到就快速结束采样器生命周期和消息处理周期完全对齐Consumer 回调模式下消息到达是异步的JMeter 的采样统计难以准确映射到每条消息的处理过程回调线程也不会受线程组并发控制数据解释起来很别扭。ack 模式是消费压测里最影响数据可信度的设置。autoAck 模式下Broker 把消息发给消费者后立即标记为已确认根本不关心消费者是否处理完毕。压测时用 autoAckTPS 数字会非常漂亮但压的是“Broker 分发速度”而不是“业务处理速度”。manualAck 模式下消费者处理完消息后调用 basicAckBroker 才真正移除消息这个 TPS 才代表真实处理能力。生产消费链路压测必须用 manualAck这是底线。prefetch 参数同样关键。basicQos(prefetch)控制消费者本地缓冲的最大未确认消息数。prefetch 1 时最保守每条消息确认后才拉下一条消息处理延迟最均衡prefetch 100 时 Broker 会一波波往消费者本地塞消息吞吐高但延迟抖动变大消息积压在消费者本地Broker 端 unacked 数量飙升。压测消费能力时prefetch 应该从 1 开始往上调找到吞吐拐点。4.2 消费端 JSR223 脚本与断言写法下面是工具包内消费者压测的 JSR223 脚本完成“取消息、算延迟、确认、计数”四件事import com.rabbitmq.client.Channel import com.rabbitmq.client.GetResponse Channel ch props.get(rmq.ch) if (ch null || !ch.isOpen()) { com.rabbitmq.client.Connection conn props.get(rmq.conn) ch conn.createChannel() props.put(rmq.ch, ch) } // prefetch 控制本地缓冲设于每次取消息之前 int prefetch Integer.parseInt(props.get(RMQ_PREFETCH)) ch.basicQos(prefetch) // autoAckfalse手动确认 GetResponse response ch.basicGet(props.get(RMQ_QUEUE), false) if (response ! null) { long deliveryTag response.getEnvelope().getDeliveryTag() byte[] body response.getBody() String msg new String(body, UTF-8) // 提取 JSON 里的发送端时间戳计算端到端延迟 // 消息格式: {seq:123,ts:1710000000000,data:...} String tsPart msg.substring(msg.indexOf(\ts\:) 5) long sendTs Long.parseLong(tsPart.substring(0, tsPart.indexOf(,))) long latency System.currentTimeMillis() - sendTs vars.put(LATENCY, String.valueOf(latency)) ch.basicAck(deliveryTag, false) // 记录累计消费数 long cnt Long.parseLong(props.get(rmq.consumedCount, 0)) props.put(rmq.consumedCount, String.valueOf(cnt 1)) prev.setSuccessful(true) prev.setResponseMessage(latency latency , consumed cnt) } else { // 队列为空避免空转刷空样本 prev.setSuccessful(false) prev.setStopThread(true) }这段脚本和生产者脚本对称复用同一个 Connection但从 props 里拿的是rmq.ch这个 Channel。prefetch 配置每次迭代都执行这是为了在压测中途调整 RMQ_PREFETCH 时能即时生效不用重启压测。basicGet(queue, false)的第二个参数就是 autoAck 开关false 表示手动确认拿到响应后必须用 deliveryTag 调用 basicAckBroker 才会删除消息。如果脚本在 basicGet 和 basicAck 之间抛异常消息会变成 unacked 状态重新连上后自动重回队列这是手动确认模式的安全机制。队列为空的处理是容易翻车的地方。如果用prev.setSuccessful(true)把空队列当作成功样本那么当生产速率跟不上消费速率时采样器会飞速空转聚合报告里 TPS 飙高但实际消费消息数原地不动产生虚高假象。工具包脚本里把空队列标记为失败并setStopThread(true)停止线程意思是告诉压测执行者队列空了消费压测跑到顶了不需要再空转。真正的消费压测目标是让队列保持在“非空但不堆积”的状态接近速率上限时反而要观察带有非空响应的采样点。4.3 观测指标队列深度、消费 TPS、延迟分桶消费压测的观测指标分三个维度。队列深度看 RabbitMQ 管理界面的 Queues 页签total 是当前堆积消息数ready 是待分发消息数unacked 是已发出但未确认的消息数。如果 unacked 长期接近 prefetch × 消费者线程数说明消费者处理不过来如果 ready 持续增长说明生产速率大于消费速率堆积是预期行为重点观察堆积增长斜率是否线性。延迟分桶看聚合报告里的响应时间分布工具包内消息体带了发送时间戳消费端算出的 latency 字段会写入线程局部变量聚合报告里能直接看到平均延迟和 90% 延迟如果延迟分布出现双峰通常是 GC 停顿或信道竞争需要回看 JMeter 的 GC 日志。消费 TPS 必须和实际消费计数对齐而不是只看聚合报告上的 TPS 列。聚合报告的 TPS 计算基于采样器执行次数空队列样本和成功消费样本都被计入前者推高数字但没有业务含义。工具包脚本里用 props 维护rmq.consumedCount压测结束后从 tearDown 线程组里把它导出这才是可信的消费总量。用总量除以压测时长得到的平均速率比聚合报告上的瞬时 TPS 更能代表真实能力。5. 避坑实录JMeter 3.3 压 RabbitMQ 的五个典型事故5.1 连接被重置日志刷屏“accepting new connections”现象压测启动后几十秒JMeter 大量采样报错错误信息是Connection reset by peer同时 RabbitMQ 服务端日志出现大量连接建立和关闭记录节点 CPU 飙高但业务其实没有流量。原因压测线程数大于 50 时每个线程都调用了factory.newConnection()一瞬间在 Broker 上创建了海量 TCP 连接RabbitMQ 默认的连接数上限被触发操作系统文件描述符也接近耗尽服务端开始强制重置旧连接。解决把 Connection 创建挪到 setUp 线程组里全局只保留一个 Connection压测线程组内部每次迭代时创建 Channel用完即关。改完后再跑Broker 端连接数稳定在个位数吞吐曲线不再剧烈抖动。5.2 guest 账号远程访问被拒握手阶段直接失败现象本地用 guest 账号压测没问题代码发到测试服务器上压测远端 RabbitMQAMQP 握手直接失败服务端日志提示user guest can only connect via localhost。原因RabbitMQ 默认账号 guest 只允许回环地址访问这是出厂安全策略不是权限配置错误。解决在 RabbitMQ 管理后台创建专用压测账号授予所在 vhost 的 configure、write、read 权限权限正则建议配置得收敛一些避免压测账号能操作所有资源。生产环境给压测账号单独建 vhost压测流量与业务流量物理隔离这条经验也适用于 Kafka 等消息中间件的压测。5.3 autoAck 模式下消费 TPS 虚高消息实际没处理现象消费压测聚合报告 TPS 高达数万但业务数据库里落库条数远低于消费 TPS队列消息还在不断减少。原因消费采样器用了默认的 autoAck 行为Broker 把消息分发出去就标记为已确认消息被丢弃消费者实际只做了“收消息”这个动作处理逻辑没执行完也照样算成功。解决basicGet 时显式传 false手动确认处理完业务逻辑后再 basicAck。同时配合 prefetch 1 或 prefetch 50 观察 unacked 指标确认每条消息都走完了“取到 → 处理 → 确认”的完整链路。改完后 TPS 会明显下降但这个数字才是消费者真实能力的体现。5.4 开启发布确认但发送数与确认数对不上消息少了几十条现象生产者压测统计已发送消息 50 万条Broker 端队列实际只有 49.99 万条差异虽然小但对账不过。原因脚本里只调了basicPublish没有调用waitForConfirms或检查确认回调而basicPublish本身只保证“投递给连接”不保证 Broker 已持久化。RabbitMQ 在持久化消息落盘前的崩溃窗口里可能丢失消息。解决开启confirmSelect低 QPS 场景每条消息用waitForConfirms(timeout)同步确认高 QPS 场景改成批量确认每发 100 条调用一次waitForConfirms超时或失败时对这个批次做补偿重发。发布确认的开启会让 TPS 小幅下降这是付费买确认数据对账要求高的项目必须开。5.5 JMeter 3.3 在 JDK 9 和 JDK 8 高版本上的兼容性陷阱现象同一条 JSR223 脚本放在 JMeter 5.x 上跑正常放回 JMeter 3.3 直接抛异常还有人在新机器上装了 JDK 11JMeter 3.3 启动后脚本执行大面积报错。原因JMeter 3.3 官方支持 JDK 8内部集成的 Groovy 版本是 2.4和 JDK 9 以上的模块系统、以及新版 JDK 8 中某些内部 API 的移除不兼容。解决固定使用 JDK 8 启动 JMeter 3.3不要盲目用系统默认 Java脚本写法上只使用 Java 8 兼容语法和 Groovy 2.4 的 API避免使用 Groovy 3.0 新增的语法糖。工具包内的启动脚本把 JAVA_HOME 写死成 jdk8就是为了避免环境问题干扰压测。6. 收尾技巧用发布确认做一次端到端对账压测跑完不等于数据可用我会强制做一道对账发送数 确认数 消费数。三个数对不上这轮压测的吞吐、延迟再漂亮也不能拿去汇报。工具包脚本里已经在关键节点埋好了计数逻辑生产者侧维护rmq.sentCountBroker 返回发布确认后累加rmq.confirmedCount消费者侧维护rmq.consumedCount最后在 tearDown 线程组里把三个数打印出来。// tearDown 线程组内 JSR223 脚本 long sent Long.parseLong(props.get(rmq.sentCount, 0)) long confirmed Long.parseLong(props.get(rmq.confirmedCount, 0)) long consumed Long.parseLong(props.get(rmq.consumedCount, 0)) log.info(audit: sent sent , confirmed confirmed , consumed consumed) if (sent ! confirmed || confirmed ! consumed) { prev.setSuccessful(false) prev.setResponseMessage(audit failed: sent/confirmed/consumed mismatch) }对账通过的标准是三值完全相等。sent confirmed说明有消息没等到确认要么是发布确认超时被吞要么是脚本在 waitForConfirms 之前就继续跑下一轮了confirmed consumed说明消费端跟不上或者消费者线程已经因为队列空提前退出压测时长内没有消费完所有确认消息。压测前建议先把目标队列 purge 清空让消费计数从零开始否则旧消息混进来对账永远差一截。对账之外还有一个经常被忽略的细节压测结束时要把 JSR223 脚本里创建的 Connection 和 Channel 显式关闭。JMeter 停止压测时线程组会被强制终止脚本里创建的连接没有默认的清理逻辑Broker 上残留的连接会占用文件描述符下一轮压测可能因为这个原因复现第一类事故。tearDown 线程组里加一行conn.close()就能给每轮压测画上干净的句号。我已经养成一个习惯每轮压测结束先看对账三兄弟再决定要不要看聚合报告。有一次夜间压测发送量一百二十万确认量一百二十万消费只到一百一十九万团队排查了半宿消费者性能瓶颈最后发现是有几条超长消息在消费端解析 JSON 时抛了异常被非则处理逻辑吞掉没进入 ack 流程。从那以后我封板压测结果之前都强制走一遍对账确认对不上就先查代码不急着看图表。这套工具包帮我把环境、脚本、对账链路一次性搭齐了剩下要做的只是换参数跑场景。希望帮到你。本文还有配套的精品资源点击获取