RocketMq(七)消息堆积处理方式

一、产生原因：

消息堆积顾名思义就是消息队列中堆积了大量未被处理的消息，主要发生在高并发的场景下，生产者发送消息的速率远大于消费者组消息的速度。产生的原因有：

（1）新上线的消费者的消费逻辑存在Bug，导致消息不能被正常消费。某些消息消费失败，或者消费超时，从而导致消息被大量堆积。

（2）消费者实例宕机或者由于网络的原因不能连上Broker集群。消费者实例可能是单节点或者机房网络不好的情况。

（3）生产者短时间内大量发送消息到Broker端，消费者的消费能力不足。消费者消费消息是一些比较耗时的操作。这导致消费者的消费速率远低于生产者发送速率。

二、解决方法：

1、集群部署：消费者实例采用多实例，异地多活的方式，确保极端的情况下都能有消费者能够正常消费消息。增加消费者节点（集群），提高消费者的消费能力（或异步处理进行消费）。

2、提高消费者的消费速率：

（1）同一个消费者组下增加消费者实例：比如Topic中有8个队列，那么可以将消费者数量最多增加到8个（多了则是空闲的）。在RocketMQ中某个topic下的某个队列只能被同一消费者组中的某个消费者消费，如果消费者数量少于Queue的数量，那么有可能会出现消费不均的情况。

（2）提高单个消费者的消费并行线程：RocketMQ 支持批量消费消息，可以通过修改DefaultMQPushConsumer 消费者类的consumeThreadMin（最少消费线程数），以及consumeThreadMax（最大消费线程数）来提高单个消费者的消费能力。

（3）批量消费消息：某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时 1 s，一次处理 10 个订单可能也只耗时 2 s，这样即可大幅度提高消费的吞吐量。建议使用5.x SDK的SimpleConsumer，每次接口调用设置批次大小，一次性拉取消费多条消息。

3、扩展mq的节点（broker）来分担负载，或者提高队列。

4、调整消息队列的参数，优化性能
5、监控和管理消息队列（蓝鲸），及时发现问题并采取相应的措施
6、把监控阻塞的队列写成定时脚本并输出结果到/tmp/stdout.txt文件中,定时脚本的内容是
# crontab 定时监控阻塞的消息队列情况脚本 
kubectl -n blueking exec  bk-rabbitmq-0 -- rabbitmqctl list_queues -p bkmonitor|grep celery_alert_builder  |tee -a /tmp/stdout.txt
# 写入crontab定时方法,也可以直接执行 crontab -e ;然后写入定时脚本内容保存
echo "*/5 * * * * kubectl -n blueking exec  bk-rabbitmq-0 -- rabbitmqctl list_queues -p bkmonitor|grep celery_alert_builder  |tee -a /tmp/stdout.txt" > /var/spool/cron/root

三、临时解决方法

1、步骤：

临时扩容，快速处理积压的消息：

（1）先修复 consumer 的问题，确保其恢复消费速度，然后将现有的 consumer 都停掉；

（2）临时创建原先 N 倍数量的 queue ，然后写一个临时分发数据的消费者程序，将该程序部署上去消费队列中积压的数据，消费之后不做任何耗时处理，直接均匀轮询写入临时建立好的 N 倍数量的 queue 中；

（3）接着，临时征用 N 倍的机器来部署 consumer，每个 consumer 消费一个临时 queue 的数据

（4）等快速消费完积压数据之后，恢复原先部署架构 ，重新用原先的 consumer 机器消费消息。

这种做法相当于临时将 queue 资源和 consumer 资源扩大 N 倍，以正常 N 倍速度消费。

2、恢复队列中丢失的数据：

如果使用的是 rabbitMQ，并且设置了过期时间，消息在 queue 里积压超过一定的时间会被 rabbitmq 清理掉，导致数据丢失。这种情况下，实际上队列中没有什么消息挤压，而是丢了大量的消息。所以就不能说增加 consumer 消费积压的数据了，这种情况可以采取 “批量重导” 的方案来进行解决。在流量低峰期，写一个程序，手动去查询丢失的那部分数据，然后将消息重新发送到mq里面，把丢失的数据重新补回来。

3、MQ长时间未处理导致MQ写满的情况

如果消息积压在MQ里，并且长时间都没处理掉，导致MQ都快写满了，这种情况肯定是临时扩容方案执行太慢，这种时候只好采用 “丢弃+批量重导” 的方式来解决了。首先，临时写个程序，连接到mq里面消费数据，消费一个丢弃一个，快速消费掉积压的消息，降低MQ的压力，然后在流量低峰期时去手动查询重导丢失的这部分数据。