消息队列-消息积压

消息积压

性能优化

性能的优化主要在生产者和消费者这俩业务逻辑

mq自身性能，作为API使用者，无需过度关注。因大多mq业务，mq本身处理能力远大于业务系统。主流mq的单个节点，消息收发性能可达几万到几十万条消息每秒，还可以水平扩展Broker实例数倍增处理能力。而一般业务系统需处理的业务逻辑远比消息队列复杂，单节点每秒可处理几百到几千次请求，性能已经算很好了。所以mq性能优化，更关注在消息收发两端，业务代码怎么和mq协作达到最佳性能

生产端

生产端业务代码处理性能实际上和mq关系不大，都是先执行自己的业务逻辑，最后再发送信息。如果你的代码发送消息的性能上不去，需要先检查是否因为发消息前的业务逻辑耗费太多时间导致。

对于发消息的业务逻辑，只需要注意设置合适并发和同步大小，即可达到很好发送性能。

这是因为Producer发消息给Broker，Broker收到消息后返回确认响应，这是一次完整交互。假设一次交互的平均时延是1ms，就算是单线程发送，每次只发1跳，则每秒只发1000条消息，这并不能压榨mq性能

无论是增加每次发送消息的批量大小，增加并发都能倍增发送性能，那么选择批量发送还是增加并发呢？

这取决于发送端的业务性质：

• 如果发送端是个微服务，主要接受RPC请求处理在线业务。那么微服务在处理每次请求时，就在当前线程直接发消息即可，因为所有RPC框架都是多线程支持并发，自然可以并行发送消息，且在线业务比较在意请求响应时间。这时就可以通过并发提升发送性能更好
• 如果是离线分析系统，并不关心时延，更关注整个系统的吞吐量，这时候用批量发送就更适合了

消费端

使用mq的时候，大部分性能问题都出现在消费端。如果消费速度跟不上发送端生产消息的速度，就会造成消息积压。如果这种性能倒挂问题只是暂时的，那还好，只要消费端的性能恢复之后，超过发送端的性能，那积压的消息是可以逐渐被消化掉的

若消费速