关于RabbitMQ性能问题的几点分析

目前对RabbitMQ的使用才刚刚开始，下面提出的问题，也许是由于对服务器的配置或者对客户端API还不了解导致的。欢迎斧正。

一． 要避免流控机制触发

• 服务端默认配置是当内存使用达到40%，磁盘空闲空间小于50M，即启动内存报警，磁盘报警；报警后服务端触发流控（flow control）机制。一般地，当发布端发送消息速度快于订阅端消费消息的速度时，队列中堆积了大量的消息，导致报警，就会触发流控机制。

• 触发流控机制后，RabbitMQ服务端接收发布来的消息会变慢，使得进入队列的消息减少；与此同时RabbitMQ服务端的消息推送也会受到极大的影响，测试发现，服务端推送消息的频率会大幅下降，等待下一次推送的时间，有时等1分钟，有时5分钟，甚至30分钟。

• 一旦触发流控，将导致RabbitMQ服务端性能恶化，推送消息也会变得非常缓慢；因此要做好数据设计，使得发送速率和接收速率保持平衡，而不至于引起服务器堆积大量消息，进而引发流控。通过增加服务器集群节点，增加消费者，来避免流控发生，治标不治本，而且成本高。

第一次修改本节

• 服务器单节点，单网卡全双工情况下，测试发现发布速度过快，压满发布PC机带宽，对于服务器来说，下行（接收）带宽也会压满，可是上行（转发递送）带宽却出现了明显的下降，似乎有一个争抢。这可能是导致触发流控的原因。

二． 从底层取数据一定要非常及时

• 订阅端每隔500MS调用一次amqp_consume_message接口函数从socket上获取数据，正常情况下，服务器每次会推送几百条消息，而且推送的频率会比较高；导致订阅端的本机socket缓冲区会很快存满，导致很多消息无法进行缓存，而被丢掉。

• 测试发现(单线程订阅):

用例	发布消息条数	调用amqp_comsume_message间隔(MS)	实际接收条数
1	630	500	269
2	695	470	269
3	513	460	513
4	503	450	503

三． 消息大小不要超过4MB

• 客户端与RabbitMQ服务端的最大帧是128K，但消息大小却可支持数MB，这是可能是因为底层做了拆包组包的，目前我还未查看底层代码。

• 用线程来模拟50个发布者和50个订阅者；消息包大小由1K到10MB，当包大小达到4.5MB时，服务器的性能出现明显的异常，传输率尤其是每秒订阅消息的数量，出现波动，不稳定；同时有一部分订阅者的TCP连接出现断开的现象。可能是客户端底层或者RabbitMQ服务端在进行拆包，组包的时候，出现了明显的压力，而导致异常的发生。

• 超过4MB的消息，最好先进行分包。

第一次修改本节

• 由于用线程模拟大量发布者，且是服务器单节点，受客户端主机网卡的限制，发布线程没有速度控制，导致有大量数据发送，服务器带宽下行速率也满负荷，上行带宽却明显低于下行速率，导致服务器内存有大量消息堆积，进而触发RabbitMQ服务器paging操作，才出现了上述不稳定和订阅者断开现象。对发布端做适当流量控制，断开连接现象不再出现，但每秒消息数仍然不稳定。