Rabbit测试及其方案

转载：https://www.2cto.com/kf/201609/548190.html

个消息没有回应，则MQ不会再往消费者A中发消息，直到收到消息确认后才会再次发送。

Ack：消息确认。

：启动一个生产者，无消费者。

条消息，磁盘写入是6250/s

当消息的堆积量达到40W以上时，每秒进入队列的速率就会降到4500~5000/s之间

 
 

：启动三个生产者，无消费者。

 
 

条消息，磁盘写入是6500/s

 
 

：启动10个生产者，无消费者

 
 

条消息，磁盘写入是7300/s

 
 

：启动20个生产者，无消费者

 
 

个生成者是8500，经过反复测试最终发现20~25个生产者效率最高。

 
 

个消费者，Qos为0，默认ack接收到消息马上返回。

测试结果：每秒消费8000Qps

 
 

：启动无生产者，1个消费者，Qos为1，默认应答接收到消息马上返回。

测试结果：每秒消费310Qps;

 
 

：启动无生产者，1个消费者，Qos为1，默认不应答接收到消息马上返回

 
 

测试结果：每秒消费11500Qps;

 
 

：启动无生产者，一个消费者，Qos为10，默认ack接收到消息马上返回。

 
 

 
 

：启动1个生产者，1个消费者，Qos为10，默认Ack,接收到消息后马上返回。

 
 

测试结果：生成4000Qps/s消费1000Qps/s

 
 

：启动1个生成者，1个消费者，Qos为10，默认Ack,接收到消息休眠10ms

 
 

测试结果：生产4500Qps/s消费10Qps/s

 
 

：启动1个生产者，1个连接，10个消费者，Qos为100，默认Ack,接收到消息休眠10ms

 
 

测试结果：生产5000qps/s消费500qps/s

这说明一味的增加channel开启consumer应该是有瓶颈的,随着consumer的增加,消费效率应该也不会有太大的增加,接着测试

 
 

：启动一个生产者，1个连接，30个消费者，Qos为100，默认Ack，接收到消息休眠10ms

测试结果：生产4500qps/s消费450qps/s

左右,感觉要到瓶颈了.后面我尝试过consumer_size=50,也是这个值,直到consumer_size=17的时候就是500/s,再增加consumer也不会增加效率了.

从数据上来看感觉是一个连接里面channel有一个上限值,再多也处理不完了,那可以考虑尝试增加connection来试试是否能够增加消费能力

 
 

：启动1个生产者，3个连接，每个连接里面创建17个消费者，Qos为100，默认Ack,接收到消息休眠10ms，用来模拟业务处理时间

 
 

测试结果：生产4320qps/s消费1500qps/s

：启动一个生产者，10个连接，每个连接里面创建17个消费者，Qos为100，默认Ack,接收到消息休眠10ms，用来模拟业务处理时间

 
 

总结

通过以上的测试,我们基本上得出以下几个结论:

1.生产者生产消息过快,无论是否有消费者,都会触发流控,不同的是流控强度随消费者个数加强.

2.一旦有消费者连接,就会对生产者的消息生产效率产生影响(在触发流控之后)

3.在每个连接里面在创建相应数量的consumer,可以增加消费能力,但是也是有上限的,我的
测试中上限是17

4.创建多个连接,并且每个每个连接里面consumer设置到上限数量,可以进一步增加消费能力

5.在消息堆积的情况下,消费者数量与生产者的生产效率成反比

6.在没有消息堆积的情况下,设置得当的话,基本上可以做到生产与消费同步(测试的最大值为13000+/s,加大连接数可能还会提高)