转载：https://www.2cto.com/kf/201609/548190.html
Qos：举例说明：Qos=2如果消费者A 有2个消息没有回应，则MQ不会再往消费者A中发消息，直到收到消息确认后才会再次发送。
Ack：消息确认。
方案1：启动一个生产者，无消费者。
测试结果：每秒生产大约6250条消息，磁盘写入是6250/s
当消息的堆积量达到40W以上时，每秒进入队列的速率就会降到4500~5000/s之间
方案2：启动三个生产者，无消费者。
测试结果：每秒生产大约6500条消息，磁盘写入是6500/s
方案3：启动10个生产者，无消费者
测试结果：每秒生产大约7300条消息，磁盘写入是7300/s
方案4：启动20个生产者，无消费者
测试结果：生产9000qps/s ,启动30个生成者是8500，经过反复测试最终发现20~25个生产者效率最高。
方案5: 启动无生产者，1个消费者，Qos为0，默认ack接收到消息马上返回。
测试结果：每秒消费8000Qps
方案6：启动无生产者，1个消费者，Qos为1，默认应答接收到消息马上返回。
测试结果：每秒消费310Qps;
方案7：启动无生产者，1个消费者，Qos为1，默认不应答接收到消息马上返回
测试结果：每秒消费11500Qps;
方案8：启动无生产者，一个消费者，Qos为10，默认ack接收到消息马上返回。
方案9：启动1个生产者，1个消费者，Qos为10，默认Ack,接收到消息后马上返回。
测试结果：生成4000Qps/s消费1000Qps/s
方案10：启动1个生成者，1个消费者，Qos为10，默认Ack,接收到消息休眠10ms
测试结果：生产4500Qps/s消费10Qps/s
方案11：启动1个生产者，1个连接，10个消费者，Qos为100，默认Ack,接收到消息休眠10ms
测试结果：生产5000qps/s消费500qps/s
这说明一味的增加channel开启consumer应该是有瓶颈的,随着consumer的增加,消费效率应该也不会有太大的增加,接着测试
方案12：启动一个生产者，1个连接，30个消费者，Qos为100，默认Ack，接收到消息休眠10ms
测试结果：生产4500qps/s消费450qps/s
从结果来看,consumer增加了三倍,但是消费速率基本在1400左右,感觉要到瓶颈了.后面我尝试过consumer_size=50,也是这个值,直到consumer_size=17的时候就是500/s,再增加consumer也不会增加效率了.
从数据上来看感觉是一个连接里面channel有一个上限值,再多也处理不完了,那可以考虑尝试增加connection来试试是否能够增加消费能力
方案13：启动1个生产者，3个连接，每个连接里面创建17个消费者，Qos为100，默认Ack,接收到消息休眠10ms，用来模拟业务处理时间
测试结果：生产4320qps/s消费1500qps/s
方案14：启动一个生产者，10个连接，每个连接里面创建17个消费者，Qos为100，默认Ack,接收到消息休眠10ms，用来模拟业务处理时间
总结
通过以上的测试,我们基本上得出以下几个结论:
1.生产者生产消息过快,无论是否有消费者,都会触发流控,不同的是流控强度随消费者个数加强.
2.一旦有消费者连接,就会对生产者的消息生产效率产生影响(在触发流控之后)
3.在每个连接里面在创建相应数量的consumer,可以增加消费能力,但是也是有上限的,我的
测试中上限是17
4.创建多个连接,并且每个每个连接里面consumer设置到上限数量,可以进一步增加消费能力
5.在消息堆积的情况下,消费者数量与生产者的生产效率成反比
6.在没有消息堆积的情况下,设置得当的话,基本上可以做到生产与消费同步(测试的最大值为13000+/s,加大连接数可能还会提高)