什么是消息积压？

大量消息被堆积在broker端，没有被消费。

为什么会消息积压？

宏观角度主要原因是：producer端生产速度 > consumer端消费速度。

导致producer端生产速度 > consumer端消费速度的情况有多种：

1. 设计的时候就没有考虑消费速度要大于生产速度，这种情况最不应该。
2. 某一时刻消息积压上涨
   1. 比如说抢购，导致生产端一下子并发量飙升，考虑水平扩容或者服务降级。
   2. 消费端有很多消费失败，导致消费性能下降

消息积压了该怎么办？

这里首先得有一个认识：消息队列本身的处理能力要远大于业务系统的处理能力。因此主要考虑业务逻辑中的性能优化。

紧急处理

问题的根在于consumer端消费速度慢导致的，最直接的方法就是水平扩容，增加消费端的并发数，来提升总体的消费性能。

需要注意的是：在Kafka或RocketMQ中 在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区（也叫队列）数量，确保 Consumer 的实例数和分区数量是相等的。 否则水平扩容之后也是没有效果的。

紧急处理之后进行Consumer端优化

只要针对consumer端的业务逻辑进行优化。

我们的业务代码怎么和消息队列配合，达到一个最佳的性能？

producer端

发送端性能上不去，你需要优先检查一下，是不是发消息之前的业务逻辑耗时太多导致的。

提升发送性能的方法：设置合适的并发和批量大小。

Producer 发消息给 Broker，Broker 收到消息后返回确认响应，这是一次完整的交互。

提升发送性能就是为了在单位时间内增加交互的消息量。

并发方式：对于响应时间短的友好

批量方式：对吞吐量大的友好

耗时分析

• 1.准备发送：发送端准备数据、序列化消息、构造请求等逻辑的时间
• 2.消息从producer端网络传输到broker端
• 3.broker端处理消息
• 4.消息响应从broker端网络传输到producer端

broker端

刚才已经提过了，消费队列性能远大于业务系统的处理能力，所以broker端的性能不用考虑，要考虑也可以通过水平扩容broker达到很好的效果。

consumer端

如上，只要针对consumer端的业务逻辑进行优化，或者进行水平扩容，且在broker增加分区。

总结