RabbitMQ性能测试工具的使用

背景：最近看RabbitMQ相关知识，顺便了解了一下他的性能测试工具。RabbitMQ Performance Testing Tools（PerfTest）是一款开源的性能测试工具。

工具：rabbitmq_server-3.7.8 + rabbitmq-perf-test-2.2.0 + Window7

1. RabbitMQ基本概念

RabbitMQ Broker：也叫broker server，它是一种传输服务。他的角色就是维护一条从Producer到Consumer的路线，保证数据能够按照指定的方式进行传输。但是这个保证也不是100%的保证，但是对于普通的应用来说这已经足够了。当然对于商业系统来说，可以再做一层数据一致性的guard，就可以彻底保证系统的一致性了。
Producer：消息生产者，即数据的发送方。消息生产者连接RabbitMQ服务器然后将消息投递到Exchange。
Consumer：消息消费者，即数据的接收方。消息消费者订阅队列，RabbitMQ将Queue中的消息发送到消息消费者。
Exchange：生产者将消息发送到Exchange（交换器），由Exchange将消息路由到一个或多个Queue中（或者丢弃）。Exchange并不存储消息。RabbitMQ中的Exchange有fanout、direct、topic、headers四种类型，每种类型对应不同的路由规则，后面详细介绍这四种类型。
Queue：（队列）是RabbitMQ的内部对象，用于存储消息。消息消费者就是通过订阅队列来获取消息的，RabbitMQ中的消息都只能存储在Queue中，生产者生产消息并最终投递到Queue中，消费者可以从Queue中获取消息并消费。多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
RoutingKey：生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则，而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。RabbitMQ为routing key设定的长度限制为255 bytes。
Connection：（连接）。Producer和Consumer都是通过TCP连接到RabbitMQ Server的。以后我们可以看到，程序的起始处就是建立这个TCP连接。
Channels：（信道）。它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。
Exchange Types：
fanout：fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中。生产者发送到Exchange的所有消息都会路由到绑定的Queue，并最终被两个消费者消费。
direct：direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key完全匹配的Queue中。（在实际使用RabbitMQ的过程中并没有binding key这个参数，只有routing key，为了区分我们把交换机和队列绑定时传的参数叫binding key，把发送消息时带的这个参数叫routing key）
topic：前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但direct是完全匹配，而通过topic可以进行模糊匹配routing key为一个句点号“. ”分隔的字符串（我们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit” binding key与routing key一样也是句点号“. ”分隔的字符串 binding key中可以存在两种特殊字符“”与“#”，用于做模糊匹配，其中“”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）
headers：headers类型的Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue。

注：上述文字来自：https://blog.csdn.net/super_rd/article/details/70238869。感谢作者~~

2 .RabbitMQ性能测试工具

1）介绍

RabbitMQ有一个测试吞吐量的性能测试工具PerfTest。它是基于Java开发的客户端。可以配置为模拟基本和高级两种负载。源码下载地址：https://bintray.com/rabbitmq/java-tools/perf-test。

2）使用

a. PerfTest的安装

将html目录中的数据拷贝到bin目录下：

将examples目录中的文件也拷贝到bin目录：

3）准备测试场景

这里的测试场景为：2个Producers将在30秒内向RabbitMQ发送消息。与此同时，1个Consumer将消费这些消息。

4）执行测试

在bin目录下，执行如下命令，收集的数据会在public-consume-result.js中出现。

# runjava com.rabbitmq.perf.PerfTestMulti public-consume-spec.js public-consume-result.js

5）查看结果

a. 该工具使用HTML代码展示执行结果。在bin目录下新建文件：publish-consume-result.html，代码如下：

b.开启webserver。切换到bin的上一层目录，执行如下命令：

# runjava com.rabbitmq.perf.WebServer. ./ 9099

这里，./为publish-consume-result.html所在目录，9099为监听端口。

在浏览器中输入：http://<RabbitMQ的IP>:9099/publish-consume-result.html。展示结果如下：

在项目的环境中，出现了这样的场景：发送消息速率(send-msg-rate)波动较大，其波动幅度随着时间增长逐渐缩小；接收消息的速率(recv-msg-rate)较为平缓，消息的延迟(avg-latency)较大。发送消息速率波幅的逐渐减小是由于RabbitMQ自身的限流导致，消息的延迟较大是因为有2个Producers在生产消息，而只有1个Consumer在消费，因此这里可以考虑增加多一些的Consumer。

3. 常见问题

1）缺少“guest”账号。

报错：ACCESS_REFUSED。