测试目标
性能相关情况
集群稳定性
集群的高用性
机器情况
rabbitmq集群情况
3个节点，节点服务器均为4核8G
每个节点均为磁盘节点
使用镜像队列
压测机器情况
4核8G
测试工具
rabbitmq-perf-test
PerfTest是一个基于Java客户端的吞吐量测试工具，可以将其配置为模拟基本工作负载和更高级的工作负载。PerfTest还有一些额外的工具，可以生成输出的HTML图形。
RabbitMQ集群可能受到多种因素的限制，从基础架构级别的约束（例如，网络带宽）到RabbitMQ配置和拓扑，再到发布和使用的应用程序。PerfTest可以演示节点或节点集群的基准性能。
参考文档
https://rabbitmq.github.io/rabbitmq-perf-test/stable/htmlsingle/#basic-usage
https://github.com/rabbitmq/rabbitmq-perf-test/blob/master/html/README.md
测试步骤
跑统计：bin/runjava com.rabbitmq.perf.PerfTestMulti html/test1/spec.js html/test1/result.js
起服务看结果：bin/runjava com.rabbitmq.perf.WebServer 服务器IP地址:8080/test1/result.html
测试总结
一开始进行单场景脚本测试时，发送速率也基本维持在35k/s左右，无法往上涨；开启多场景多脚本同步进行施加压力之后，发送速率也无法上升，反而一直在降，同时压测机器的负载也很高，性能跟不上。调整升级压测机器后，当我们多场景多脚本进行施压时，发送速率依旧变化不大，这是因为rabbitmq有相应的流控机制：
服务端默认配置是当内存使用达到40%，磁盘空闲空间小于50M，即启动内存报警，磁盘报警；报警后服务端触发流控（flowcontrol）机制。
一般地，当发布端发送消息速度快于订阅端消费消息的速度时，队列中堆积了大量的消息，导致报警，就会触发流控机制。
触发流控机制后，RabbitMQ服务端接收发布来的消息会变慢，使得进入队列的消息减少；
与此同时RabbitMQ服务端的消息推送也会受到极大的影响，测试发现，服务端推送消息的频率会大幅下降，等待下一次推送的时间，有时等1分钟，有时5分钟，甚至30分钟。
一旦触发流控，将导致RabbitMQ服务端性能恶化，推送消息也会变得非常缓慢；
调整测试脚本，增大生产者的并发数量到1000，5个队列，50个消费者，此时rabbitmq节点1的负载被打满；然后依次不停降低生产者和消费者的并发数量，直至生产者与消费者均只为30的场景，发现rabbitmq节点1服务器的cpu负载均很高，此时发现rabbitmq节点1服务器的cpu资源几乎都被四个线程也即rabbitmq的调取器线程占用，通过调整rabbitmq的调度器线程数量，我们发现发现速率以及服务器cpu负载有一定的变化，rabbitmq 单节点的瓶颈在于其调度器的线程数：
4个线程全打开时，发送速率限制在了35k/s，此时空闲的cpu最大不到10%
打开3个调度器线程时，发送速率限制在25k/s，此时空闲的cpu最大为25%
打开2个调度器线程时，发送速率限制在20k/s，此时空闲的cpu最大为30%
因此，我们可以通过以下措施来提升rabbitmq 的服务性能：
我们应当尽量避免触发rabbitmq的流控机制，要做好数据设计，使得发送速率和接收速率保持平衡，而不至于引起服务器堆积大量消息，进而引发流控。通过增加服务器集群节点，增加消费者，来避免流控发生，治标不治本，而且成本高。
如果当前的性能达不到业务要求时，可以升级服务器，将服务器由4核升级到8核，增加rabbitmq的调度器线程数量，来提升性能。
基准测试部分场景结果
1个节点，节点内存为3G，只发布不消费，1个队列，10个消费者，生产速率上限约为60k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为3G，只发布不消费，1个队列，15个生产者，上限约为70k/s，发送速率为0时是触发了rabbitmq的流控机制
3、1个节点，节点内存为3G，只发布不消费，1个队列，30个生产者，上限约为60k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为3G，只发布不消费，1个队列，60个生产者，上限约为60k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为4G，只发布不消费，1个队列，30个生产者，上限约为70k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为4G，生产者大于消费者，1个队列，30个生产者，10个消费者，发送速率上限约为50k/s，消费速率上限约为25k/s
1个节点，节点内存为4G，生产者大于消费者，1个队列，30个生产者，15个消费者，发送速率上限约为60k/s，消费速率上限约为35k/s
1个节点，节点内存为4G，生产者大于消费者，1个队列，30个生产者，30个消费者，发送速率上限约为60k/s，消费速率上限约为35k/s
1个节点，节点内存为4G，生产者大于消费者，2个队列，30个生产者，30个消费者，发送速率上限约为60k/s，消费速率上限约为45k/s
1个节点，节点内存为4G，生产者大于消费者，1个队列，5个消费者，生产者从[1,5,10,15]逐步增加，消息体的大小由[0, 1000, 5000, 10000, 50000]逐步增加，下图的rate为发送速率
1个节点，节点内存为4G，生产者大于消费者，3个队列，5个消费者，生产者从[1,5,10,15]逐步增加，消息量由[0, 1000, 5000, 10000, 50000]逐步增加，消费速率约等于三个队列加总的发送速率
过程中队列有积压
1个节点，节点内存为4G，生产者大于消费者，1个队列，生产者和消费者数量均从[1, 5, 10, 15, 20]逐步增加，前台查看发送和接收速率基本持平，大部分在25k/s-30k/s
11、1个节点，节点内存为4G，生产者大于消费者，4个队列，生产者和消费者数量均从[1, 5, 10,15]逐步增加
