RabbitMQ消息队列阻塞处理

目录

一、分析思路

二、mq队列阻塞

二、查看MQ消息队列情况

 三、消息队列阻塞临时处理

 四、消息队列阻塞处理

---

一、分析思路

RabbitMQ 消息队列阻塞的解决方法可以有多种途径，以下是几种常见的解决方案：

1. 增加消费者：如果消息队列的消费者数量不足，可能会导致消息堆积和阻塞。可以尝试增加消费者的数量，以提高消息的处理速度。

2. 提高消费者的处理能力：检查消费者的代码逻辑和处理方式，确保其能够高效地处理消息。可以优化消费者的代码，减少处理时间，提高处理效率。

3. 增加 RabbitMQ 的节点和队列：如果消息队列的负载过高，可以考虑增加 RabbitMQ 的节点和队列来分担负载。可以通过水平扩展的方式增加节点，使用集群模式来提高消息队列的处理能力。

4. 调整 RabbitMQ 的参数：可以根据实际需求和系统资源情况，调整 RabbitMQ 的参数，以提高性能和吞吐量。可以调整参数如 prefetch_count、channel_max、connection_max 等，来优化消息的处理和队列的性能。

5. 使用消息确认机制：在消息队列的消费端，可以使用消息确认机制来确保消息的可靠性处理。消费者在处理完消息后，发送确认消息给 RabbitMQ，以告知消息已经成功处理。这样可以避免消息的重复消费和丢失。

6. 监控和管理消息队列：使用监控工具来实时监控消息队列的状态和性能指标，及时发现问题并采取相应的措施。可以使用 RabbitMQ 自带的管理界面或第三方监控工具来监控消息队列。

7. 异步处理和批量处理：如果消息队列的负载过高，可以考虑将一些耗时较长的操作改为异步处理，或者批量处理多条消息，以减少消息队列的阻塞。

请注意，解决消息队列阻塞问题需要根据具体情况进行分析和优化。可以结合实际业务需求、系统资源和性能指标来选择合适的解决方案。

二、mq队列阻塞

        企业微信频繁接收到蓝鲸运维平台消息组件消息队列阻塞的告警，并且消息队列堆积的比较严重，通过企业告警以及蓝鲸平台集群监控都可以得知阻塞的队列是: celery_alert_builder

       

        说明：企业微信通知和平台集群监控到的消息堆积数值不一致是因为这两张图我处理后从历史记录不同时间的截图，毕竟找不到同一时间的截图了；读者可以完全消息堆积的数值即可，只需要，截图更多是表明了分析思路和突出消息队里堆积的现象。

二、查看MQ消息队列情况

        登录RabbitMQ容器使用命令行查看阻塞的消息队列情况。(由于我写文档截图的时候已经把堆积的消息问题处理了，所以看的消息数值是9，消息阻塞的时候该值实际上和收到的告警的通知告警的数值是一致的)

# k8s环境rabbitmq实例所在的命名空间是： blueking 
# rabbitmq的实例名：bk-rabbitmq-0
# rabbitmq命令行工具： rabbitmqctl
# rabbitmq 阻塞的队列所在的 vhost是: bkmonitor
kubectl -n blueking exec  bk-rabbitmq-0 -- rabbitmqctl list_queues -p bkmonitor

 三、消息队列阻塞临时处理

        由于我们环境该消息队列保存的内容都是根告警有关的信息，和业务不存在关系，在忽略告警的情景可以直接将该队列的消息清零。

# 清理消息队列命令
kubectl -n blueking exec  bk-rabbitmq-0 -- rabbitmqctl purge_queue celery_alert_builder  -p bkmonitor

 四、消息队列阻塞处理

        通过第一点的分析思路可以得知，比较容易的解决办法是找出从消费端来分析消息队列阻塞的原因，并且从现象得知，消息是可以消费只是消费的比较慢，消费端跟不上生产端的速度：

1.   限制生产端的消息产生速度，此方法不太符合实际场景
2. 增加消费端的消费速度

         导致消费端消息消费能力慢的可能原因：

1. 消费端实例CPU、内存、IO读写等负载高
2. 消费端磁盘空间不足
3. 消费端代码可能有待优化（这种方案不是处理问题优先考虑方案）

        适当增加消费端资源限制 以及增加消费端实例数来提高消费端对消息队列的消费能力，我的环境该消息队列的消费端实例数原本是一个实例，最终通过将该消费端实例数量增加到3个实例，才解决了消息队列阻塞的问题。

# 经核对得知阻塞的消息队列的消费端应用是：bk-monitor-alarm-alert-worker

kubectl -n blueking scale deploy bk-monitor-alarm-alert-worker --replicas=3

        在我的环境，我把监控阻塞的队列写成定时脚本并输出结果到/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

        查看定时监控结果，可以发现增加消费端实例数后，消息队列的堆积数值程下降趋势，并且于一天后，该队列的消息消费能力几乎是算得上是实时消费。说明消息队列堆积问题通过增加消费端的消费能力得以解决。

         直接登录实例查看消息队列情况，得到的结果也说明消息堆积值是10，几乎是实时消费，说明已不存在消息队列阻塞情况，问题已解决。