RocketMQ消息堆积问题

前几天因为下游服务消费的逻辑问题，导致宕机，大量消息堆积在了MQ中，且服务一重启就立马宕机。为了快速恢复服务，我们修改了代码逻辑，接到消息打印日志后就直接丢弃，后续定位到问题再重置消费位点。

这时我又思考另一问题，如果消费逻辑没有问题，只是生产者生产信息过快，那对于RocketMQ单纯的增加消费机器能解决问题吗？

RocketMQ消费者负载均衡

阿里云官方文档：https://help.aliyun.com/zh/apsaramq-for-rocketmq/cloud-message-queue-rocketmq-5-x-series/developer-reference/load-balancing-policies-for-consumers?spm=a2c4g.11186623.0.0.3876182feee0He
首先，我们知道RocketMQ Topic下是有一个或多个queue，消息最终其实其实是投递到queue当中，能不能通过增加机器来提高消费速度就需要了解消费者负载均衡策略

消息粒度负载均衡

消息粒度负载均衡策略中，同一消费者分组内的多个消费者将按照消息粒度平均分摊主题中的所有消息，即同一个队列中的消息，可被平均分配给多个消费者共同消费。

消息粒度的负载均衡机制，是基于内部的单条消息确认语义实现的。消费者获取某条消息后，服务端会将该消息加锁，保证这条消息对其他消费者不可见，直到该消息消费成功或消费超时。因此，即使多个消费者同时消费同一队列的消息，服务端也可保证消息不会被多个消费者重复消费。

顺序消息负载机制

在顺序消息中，消息的顺序性指的是同一消息组内的多个消息之间的先后顺序。因此，顺序消息场景下，消息粒度负载均衡策略还需要保证同一消息组内的消息，按照服务端存储的先后顺序进行消费。不同消费者处理同一个消息组内的消息时，会严格按照先后顺序锁定消息状态，确保同一消息组的消息串行消费。

如上图所述，队列Queue1中有4条顺序消息，这4条消息属于同一消息组G1，存储顺序由M1到M4。在消费过程中，前面的消息M1、M2被消费者Consumer A1处理时，只要消费状态没有提交，消费者A2是无法并行消费后续的M3、M4消息的，必须等前面的消息提交消费状态后才能消费后面的消息。

队列粒度负载均衡

对于历史版本（服务端4.x/3.x版本）的消费者，包括PullConsumer、DefaultPushConsumer、DefaultPullConsumer、LitePullConsumer等，默认且仅能使用队列粒度负载均衡策略。
（这一点就很重要了）

队列粒度负载均衡策略中，同一消费者分组内的多个消费者将按照队列粒度消费消息，即每个队列仅被一个消费者消费。

如上图所示，主题中的三个队列Queue1、Queue2、Queue3被分配给消费者分组中的两个消费者，每个队列只能分配给一个消费者消费，该示例中由于队列数大于消费者数，因此，消费者A2被分配了两个队列。若队列数小于消费者数量，可能会出现部分消费者无绑定队列的情况。

队列粒度负载均衡策略保证同一个队列仅被一个消费者处理，该策略的实现依赖消费者和服务端的信息协商机制，云消息队列 RocketMQ 版并不能保证协商结果完全强一致。因此，在消费者数量、队列数量发生变化时，可能会出现短暂的队列分配结果不一致，从而导致少量消息被重复处理。

阿里云消息队列4.x/3.x查看queue数量

阿里云消息队列4.x/3.x每个Topic下queue的数量是自动分配的，没有更改的地方，控制台也没法查看。后来我想了想，消息最终是投递到queue当中，那再发消息的源码中肯定能找到queue的信息，随后我看了下源码，果然找到了。

处理方案

所以这里就需要区分情况了

1. 阿里云消息队列5.x版本，使用消息粒度负载均衡，且不是顺序消费，可以通过增加机器来提高消费速度
2. 阿里云消息队列4.x/3.x,这种情况取决于queue的数量，
   如果机器数量<queue数量，那可以增加机器，且要确保幂等。
   如果机器数量>=queue数量,这种情况可能就得考虑提高机器配置，增加单个机器的消费线程或者看看代码逻辑是否有优化空间。