简介本资源面向需要使用JMeter 3.3对RabbitMQ进行压力测试的测试工程师与后端开发人员提供一套可直接运行的实战工具包。内容围绕JMeter对AMQP协议的支持展开涵盖AMQP Sampler等插件的集成、RabbitMQ连接参数配置、线程组并发模型设计以及聚合报告等监听器的结果分析帮助读者快速搭建消息队列压测环境。压缩包共约2000个文件以1510个html、482个png、271个js、89个less等前端与文档资源为主同时包含82个jar依赖、45个jmx测试脚本、58个lang语言包及37个xml配置整体约51.92MB目录结构完整便于按模块查阅与二次修改。目前已有1089人学习下载。通过该资源读者可掌握JMeter非HTTP协议扩展的配置方法理解RabbitMQ在高并发生产与消费场景下的吞吐量、响应时间与错误率表现并获得可复用的压测脚本与排错思路。1. 从一次压测翻车说起JMeter 3.3 怎么把 RabbitMQ 压出真实瓶颈去年帮一个做订单系统的团队做性能基线他们用 JMeter 压 HTTP 接口压得好好的轮到消息队列就抓瞎了——生产端日志显示发送成功消费端却越积越多最后定位到是 RabbitMQ 的basicPublish在高并发下被信道争用拖垮。问题在于他们压根没单独压过 MQ只把 MQ 当成 HTTP 链路里的一个黑匣子。如果你也遇到类似场景想测 RabbitMQ 的吞吐上限、想验证 prefetch 参数对消费速率的影响、想复现生产环境的消息堆积那 JMeter 3.3 配合 AMQP 插件就是一条能走通的路。这篇笔记拆的就是这套组合JMeter 3.3 作为压测引擎通过插件把 AMQP 协议接进来对 RabbitMQ 做生产端和消费端的双向压测。适合已经会用 JMeter 做 HTTP 压测、但对 MQ 压测没底的一线开发和测试。下面从环境搭建讲到参数调优中间会重点说几个我踩过的坑。2. 环境搭建与插件选型JMeter 3.3 接 AMQP 的三种方案对比JMeter 原生不支持 AMQP 协议必须靠插件补。市面上能用的方案不止一种选错了后面全是返工。这一章先把选型逻辑讲清楚再落到具体安装步骤。2.1 为什么是 JMeter 3.3 AMQP 插件而不是其他组合JMeter 3.3 是 2017 年发布的版本放在今天看不算新但它对 Java 8 的兼容性稳定插件生态也成熟。很多团队的生产压测机还锁在 JDK 8 上升 JMeter 大版本反而会引入 Groovy 引擎和 JSON 处理的行为差异压测脚本要重写。所以“JMeter 3.3 AMQP 插件”这个组合在存量环境里仍然常见。AMQP 插件主要有两个来源一个是 JMeter Plugins 社区里的AMQP Publisher / AMQP Consumer基于 RabbitMQ Java Client另一个是第三方单独打包的jmeter-amqp插件。前者集成在 Plugins Manager 里装起来省事后者更新频率高但对 JMeter 3.3 的适配需要手动验证。我一般优先用 Plugins Manager 里的版本因为依赖冲突少。方案来源支持 JMeter 3.3生产/消费维护状态AMQP Publisher/ConsumerJMeter Plugins是双向社区维护jmeter-amqp 独立包第三方需验证双向不定期自定义 Java Sampler自研是按需自己扛选型结论除非你有特殊协议扩展需求否则走 Plugins Manager 装 AMQP 插件省掉依赖排查的时间。2.2 安装插件与依赖的完整步骤JMeter 3.3 装插件有两条路GUI 里的 Plugins Manager或者手动丢 jar 包。压测机通常没有外网手动方式更可控。先确认 JMeter 版本和 Java 版本# 查看 JMeter 版本输出应包含 3.3 jmeter -v # 确认 Java 版本JMeter 3.3 建议 JDK 8 java -version如果压测机不能联网手动下载插件包。需要放进lib/ext的 jar 包括# 进入 JMeter 安装目录 cd /opt/apache-jmeter-3.3 # 插件核心包放入 lib/ext cp jmeter-plugins-amqp-*.jar lib/ext/ cp jmeter-plugins-cmn-jmeter-*.jar lib/ext/ # RabbitMQ Java Client 及其依赖放入 lib cp amqp-client-*.jar lib/ cp slf4j-api-*.jar lib/逻辑说明lib/ext放的是 JMeter 组件Sampler、Config Elementlib放的是第三方库。RabbitMQ Java Client 的版本要和 RabbitMQ 服务端协议兼容3.x 服务端配 4.x 或 5.x 客户端都能跑但 5.x 客户端要求 JDK 8 以上。参数上amqp-client版本不要跨太大否则basicPublish的超时行为会变。装完重启 JMeter在添加 Sampler 时能看到AMQP Publisher和AMQP Consumer就说明成功了。如果看不到先查lib/ext里 jar 是否齐全再看 JMeter 启动日志有没有ClassNotFoundException。提示JMeter 3.3 的 Plugins Manager 在无外网环境下会卡在检查更新建议直接手动部署别在 GUI 里等。2.3 连接配置虚拟主机、用户权限与信道参数插件装好后第一件事是配连接。AMQP Publisher 的配置界面里有几个字段容易填错Virtual Host默认是/如果 RabbitMQ 里建了业务 vhost这里必须一致否则报NOT_ALLOWED。Username / Password压测账号建议单独建给configure、write、read权限即可别用 guest。Connection Timeout / Handshake Timeout默认值偏小高并发下握手容易超时我一般把 handshake 调到 10000ms。Use SSL内网压测通常关掉开了会额外消耗 CPU干扰吞吐数据。一个常见的翻车点是压测账号只给了 vhost 的权限但没给/的权限插件默认连/就失败。现象是 Sampler 全部报错但日志只写connection refused实际是权限问题。解决办法是在 RabbitMQ 管理后台把账号的 vhost 权限显式加上。3. 生产端压测AMQP Publisher 的参数配置与吞吐调优生产端压测的目标是测出 RabbitMQ 在给定消息大小、确认机制下的最大入队速率。这一章把 Publisher 的关键参数逐个拆开并给出可复现的配置步骤。3.1 Publisher 核心参数逐个拆解AMQP Publisher 的配置项里真正影响吞吐的就那么几个参数含义建议值影响Exchange交换机名按业务填填错消息直接丢Routing Key路由键按业务填影响绑定匹配Queue队列名按业务填为空时依赖交换机类型Message Body消息体固定或随机大小直接影响吞吐Delivery Mode持久化标志1 或 22 会写磁盘吞吐降一个量级Mandatory无法路由时返回falsetrue 会增加回调开销Immediate无消费者时返回false3.x 后已废弃别开其中Delivery Mode是最容易被忽略的。设成 2持久化时RabbitMQ 要把消息刷到磁盘吞吐可能从几万降到几千。压测时如果目标是测内存吞吐就设 1如果要模拟生产环境的可靠性要求就设 2但要接受吞吐下降。消息体大小也要固定。我一般用固定长度的字符串比如 512 字节避免因为消息体长度波动导致数据不可比。JMeter 里可以用RandomString函数生成固定长度内容。3.2 用 JMeter 变量和 CSV 做参数化压测真实压测不能只发同一条消息否则 RabbitMQ 的去重和路由缓存会失真。用 CSV Data Set Config 做参数化# 准备 CSV 文件每行一个 routing key 和消息体 # msg_params.csv order.create,{orderId:1001,amount:99.5} order.pay,{orderId:1002,amount:199.0} order.cancel,{orderId:1003,amount:0}在 JMeter 里加一个CSV Data Set Config文件名指向该 CSV变量名填routingKey,messageBody。然后在 AMQP Publisher 的 Routing Key 字段填${routingKey}Message Body 填${messageBody}。逻辑说明CSV 每行被一个线程读取一次Recycle on EOF 设为 true 可以循环使用。参数上Sharing Mode 选 “All threads” 时所有线程共享文件指针高并发下会有锁竞争建议选 “Current thread” 让每个线程独立读。这样压测出来的路由分布更接近真实业务。3.3 确认机制与批量发送怎么压出真实上限RabbitMQ 生产端的吞吐瓶颈往往不在服务端而在客户端等待确认的往返延迟。JMeter 的 AMQP Publisher 默认是同步等待basicAck的每条消息都要等一个 RTT。要压出真实上限得开批量确认或异步发送。插件本身不直接暴露confirmSelect的批量参数但可以通过调整线程数和消息发送节奏来逼近。我的做法是# 在 JMeter 的 user.properties 里加以下配置 # 增大连接池避免频繁建连 amqp.connection.pool.size50 # 设置客户端心跳防止长连接被服务端断开 amqp.heartbeat60然后在 Thread Group 里把线程数从 10 逐步加到 200观察Transactions per Second曲线的拐点。拐点出现的位置就是当前配置下的吞吐上限。如果曲线在某个线程数后不升反降说明客户端或服务端的某个资源到顶了常见的是信道数或文件描述符。注意压测生产端时队列如果没有消费者消息会堆在内存里达到vm_memory_high_watermark后 RabbitMQ 会阻塞生产者。现象是 TPS 突然掉到 0日志里出现blocking字样。解决办法是同时开消费端或者把队列设成 auto-delete 并限制长度。4. 消费端压测AMQP Consumer 的 prefetch 与并发模型只压生产端只能看到入队速率消费端的吞吐和延迟同样关键。AMQP Consumer 的配置逻辑和生产端不同核心在 prefetch 和并发消费模型。4.1 prefetch count 怎么设才不浪费吞吐prefetch count 决定了一个消费者在未确认前能预取多少条消息。设太小消费者频繁等网络往返设太大消息在客户端堆积内存涨得快而且一旦消费者挂掉大量未确认消息会重新入队。我一般从 1 开始压逐步加到 100、250、500观察消费速率和客户端内存。经验值是消息处理逻辑轻比如只做计数时prefetch 设 100~250 比较合适处理逻辑重比如写数据库时设 10~50避免客户端 OOM。在 AMQP Consumer 配置里Prefetch Count字段直接填数字。同时要设Auto Acknowledge为 false手动 ack 才能让 prefetch 生效。如果开了 auto ackRabbitMQ 会认为消息一发出就确认prefetch 形同虚设。4.2 多线程消费与队列分片单个消费者的吞吐有上限要压出 RabbitMQ 的整体消费能力得开多个消费者线程。JMeter 的 Thread Group 线程数就对应消费者数量。但这里有个坑多个消费者连同一个队列时RabbitMQ 是轮询投递的每个消费者拿到的消息数大致均匀。如果某个消费者处理慢消息会在它那里堆积而其他消费者空闲。要避免这种情况要么让处理逻辑尽量等长要么用多个队列做分片。分片做法是在生产端用不同的 routing key 把消息分散到多个队列消费端每个队列配一组消费者。JMeter 里可以用多个 Thread Group每个 Group 对应一个队列。这样压测出来的数据更接近生产环境的真实分布。# 声明多个队列并绑定到同一个交换机 # 在 RabbitMQ 管理后台或命令行执行 rabbitmqadmin declare queue nameorder_queue_1 durabletrue rabbitmqadmin declare queue nameorder_queue_2 durabletrue rabbitmqadmin declare binding sourceorder_exchange destinationorder_queue_1 routing_keyorder.* rabbitmqadmin declare binding sourceorder_exchange destinationorder_queue_2 routing_keypay.*逻辑说明order.*匹配order.createpay.*匹配pay.success这样消息被分到两个队列。JMeter 里建两个 Thread Group分别消费order_queue_1和order_queue_2。参数上每个 Group 的线程数根据队列预期负载分配不要平均分否则一个队列先到瓶颈。4.3 消费延迟的测量方法JMeter 的聚合报告给的是 Sampler 响应时间但 AMQP Consumer 的 Sampler 响应时间只代表“取消息”这个动作的耗时不代表端到端消费延迟。要测真实延迟得在消息体里带时间戳消费端取出后和当前时间做差。做法是在生产端的消息体里加一个sendTime字段消费端用 JMeter 的JSR223 PostProcessor解析// 在 AMQP Consumer 后加 JSR223 PostProcessor // 语言选 JavaScriptNashorn var body prev.getResponseDataAsString(); var msg JSON.parse(body); var sendTime msg.sendTime; var now Date.now(); var latency now - sendTime; // 把延迟写入 JMeter 变量供后续断言或报告使用 vars.put(consumeLatency, latency.toString());逻辑说明prev.getResponseDataAsString()拿到消息体JSON.parse解析出sendTime和Date.now()相减得到毫秒级延迟。参数上sendTime要在生产端用System.currentTimeMillis()生成别用格式化字符串解析开销大。这个延迟值可以写到 JMeter 的 sample 里最后在聚合报告中看到 P99 延迟。5. 避坑与排查压测中五个高频翻车现场这一章全是血泪经验每条都按“现象 → 原因 → 解决”写照着排查能省不少时间。5.1 现象Sampler 全部报错日志只有 connection refused原因压测账号没有目标 vhost 的权限或者 vhost 名字填错。RabbitMQ 对权限不足的连接有时不返回明确错误只断开。解决在 RabbitMQ 管理后台检查账号的 vhost 权限确保configure、write、read都有。vhost 名字区分大小写填之前复制粘贴别手敲。5.2 现象TPS 曲线在某个线程数后断崖式下跌原因RabbitMQ 触发了内存流控memory alarm生产者被阻塞。常见于队列无消费者、消息持续堆积的场景。解决压测生产端时同时开消费端或者给队列设x-max-length限制长度。临时办法是在 RabbitMQ 配置里调高vm_memory_high_watermark但生产环境别这么干。5.3 现象消费端 prefetch 设了 100但实际每次只取到 1 条原因Auto Acknowledge 没关。开了 auto ack 后RabbitMQ 认为消息发出即确认prefetch 不生效。解决在 AMQP Consumer 配置里把 Auto Acknowledge 设为 false并在 Sampler 后加手动 ack 的逻辑。插件通常有 “Acknowledge” 选项选 “After Sampler” 或类似项。5.4 现象压测跑了几分钟JMeter 报 OutOfMemoryError原因消息体太大或 prefetch 太高客户端内存里堆了大量未处理消息。JMeter 默认堆内存只有 1GB扛不住。解决改jmeter.bat或jmeter.sh里的HEAP参数调到 4GB 以上。同时降低 prefetch或者减小消息体。如果消息体必须大就在消费端加限流。5.5 现象生产端和消费端 TPS 对不上差了一个数量级原因生产端用了持久化Delivery Mode2消费端没开手动 ack或者消费逻辑里有同步写库操作。持久化消息的消费速率本身低于非持久化。解决先确认两端的 Delivery Mode 一致。如果生产端持久化、消费端也要持久化那 TPS 低是正常的别当成 bug。要对比纯吞吐两端都设非持久化再压一次。6. 进阶技巧用 JMeter 变量做动态路由与压测结果校验压到后面你会发现固定 routing key 的压测数据参考价值有限真实业务的路由是动态的。这一章说两个进阶用法动态路由和结果校验。6.1 用 Random 函数生成动态 routing keyJMeter 内置的Random函数可以生成指定范围的随机数拼进 routing key# 在 AMQP Publisher 的 Routing Key 字段填 order.${__Random(1,100)}.create这样消息会路由到order.1.create到order.100.create这一百个 key 上。如果交换机是 topic 类型绑定order.*.create的队列会收到全部消息如果绑定order.1.create只收到对应分片。这个技巧用来测 topic 交换机的匹配性能很有效。参数上__Random的范围别设太大否则 RabbitMQ 的绑定表会膨胀内存占用上升。100 到 1000 之间比较合适。6.2 用断言校验消息是否真正入队压测时最怕的是“假成功”——Sampler 没报错但消息根本没进队列。加一个响应断言# 在 AMQP Publisher 后加 Response Assertion # 勾选 Response Data模式填 OK # 如果插件返回的不是 OK断言失败更可靠的做法是压测结束后查队列深度。用rabbitmqctl list_queues name messages看目标队列的消息数和 JMeter 发送总数对比。如果差得多说明有消息被丢弃或路由失败。# 压测前后各执行一次对比队列深度 rabbitmqctl list_queues name messages consumers逻辑说明messages是队列中待消费的消息数consumers是消费者数量。压测前记录一次压测后记录一次差值应该等于发送总数减去消费总数。如果对不上检查 Mandatory 标志和备用交换机alternate exchange配置。6.3 一个我常用的压测收尾习惯每次压测跑完我不会只看 JMeter 的聚合报告。我会做三件事第一查 RabbitMQ 管理后台的message rates曲线看有没有异常尖刺第二查服务端日志有没有blocking或closing记录第三把这次压测的jmeter.log和rabbitmqctl status输出一起存档。这样下次压测出问题时有基线可对比。从那以后我每次压 MQ 都强制走一遍“生产端 消费端 队列深度校验”三件套再也没出现过“压了个寂寞”的情况。希望帮到你。本文还有配套的精品资源点击获取