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

什么是消息积压

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

如何处理

优化性能来避免消息积压

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

发送端性能优化

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

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

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

消费端性能优化

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

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

消息积压如何处理？

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

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

小结

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