消息队列消息积压了该如何处理

Posted 2023-04-08 qxlxi

什么是消息积压

消息积压在消息队列中是比较常见的问题，最直观的就是系统出现性能问题，下游系统来不及处理上有发送的消息，所以导致的消息积压。要不就是发送端发快了，要不就是消费端处理慢了。

如何处理

优化性能来避免消息积压

在性能优化的层面，我们主要关注的是生产者和消费者一收和一发业务逻辑中，因为单节点的消息队列处理能力远远大于业务系统的处理能力，并且可以通过拓展Broker来进行提升整体的处理能力。而业务能力一般1S内能处理上百的请求都是比较高的性能。

发送端性能优化

一般来说发送端如果出现性能瓶颈，需要查看具体的写入消息队列的逻辑是否业务耗时比较久，从Produer发送消息到Broker，Broker收到消息后返回ACK确认，假设是1ms，耗时主要包含以下

• 发送端准备数据、序列化消息、构造请求等逻辑的时间，也就是发送端在请求网络之前的耗时。
• 发送消息和返回响应在网络传输中的耗时
• Broker处理消息的时延
  如果是穿行执行，那么1S中 1000ms 可以处理1000个消息，并不能发挥出Kafka的全部实力。

所以可以针对不同的业务，增加并发或者是批量发送。

消费端性能优化

对于大多数的消息积压问题，都是消费端出现了性能瓶颈，导致消息积压，一般来说，如果只是由于大促或者营销导致的，那么只要消费端处理速度大于发送端速度，消息迟早可以消息完。
但是如果消费端性能一直慢，就会导致消息越积越多，一个可能导致Broker消息过多超过所存储的磁盘限制，另一个就是可能出现消息丢失的问题。

• 优化消费端程序业务逻辑的性能。比如处理一个消息花费多长时间，瓶颈是出现在那里了，数据库、还是业务逻辑或者是设计上。
• 水平扩容，增加消费端的并发数来提升总体的消费性能，比如原来是3个分区，3台机器，那就是串行执行。在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区（也叫队列）数量，确保 Consumer 的实例数和分区数量是相等的。如果 Consumer 的实例数量超过分区数量，这样的扩容实际上是没有效果的。因为对于消费者来说，在每个分区上实际上只能支持单线程消费。

消息积压如何处理？

能导致积压突然增加，最粗粒度的原因，只有两种：要么是发送变快了，要么是消费变慢了。

• 查看监控，Kafka 生产者和消费者数据。
• 紧急扩容消费端的实例数提升总体的消费能力
• 不能紧急扩容，只能关闭当天可能影响上线的功能，减少发送方发送的数据量。
• 可能存在消费失败导致，同一条消息反复消息，拖慢整个系统。
• 查看系统错误日志，是否存在问题。

小结

本篇文章我们说了当出现消息积压时，如果处理，第一首先是找到问题，或者紧急扩容分区和消费数，平时需要有意优化生产者和消费者的发送和消费消息的性能。消息出现积压先解决生产问题。

MQ——消息积压如何处理

一、消息积压的原因

1、producer生产消息突然增多

比如大促期间，抢购，秒杀业务。

2、consumer消费性能突然下降

比如消费失败时重试，程序死锁，io阻塞。

3、消费系统本身出现瓶颈

这种情况很少，对于绝大多数使用消息队列的业务来说，消息队列本身的处理能力要远大于业务系统的处理能力。主流消息队列的单个节点，消息收发的性能可以达到每秒钟处理几万至几十万条消息的水平，还可以通过水平扩展 Broker 的实例数成倍地提升处理能力。

二、解决方法

1. 临时扩容，增加消费端，用硬件提升消费速度。*注意扩容consumer的同时要扩容分区（队列）数量，因为每个分区上只能单线程消费
2. 服务降级，关闭一些非核心业务，减少消息生产。
3. 通过日志分析，监控等找到挤压原因，消息队列三部分： 上游生产者是否异常生产大量数据，中游消息队列存储层是否出现问题，下游消费速度是否变慢（消费端日志是否有大量消费失败重试，是否有死锁，是否有io阻塞），确定哪个环节出了问题
4. 根据排查解决异常部分。
5. 等待积压的消息被消费，恢复到正常状态，撤掉扩容服务器。

 

播种和收获通常不在一个季节，而中间的过程叫做坚持～