1 背景

我们在前面两个章节中，介绍了消息组件如何保证可靠性传输和顺序行消费，参考上面系列的11、12章节。

• 比如在消息生产阶段，如何保证消息发出的稳定性和可靠性；
• 在消息服务器处理阶段，如何保证消息从生产到发送出去，经过网络传输，再到达Broker服务器并被接收的这整个阶段的可靠性，即如何使用ACK机制来保证消息传递的可靠性；
• 还有就是消息消费的可靠性，Broker作为消息服务器，消息接收并持久化消息并消费的整个过程的可靠性如何保障。
  对于消息队列组件来说，这几个步骤出现问题，都有可能造成消息队列无法进行正常运行，消息堆积的情况发生。
  另外一种情况可能就是突发的流量峰值，这种一般发生在某种消费促销活动或者各种抢购、竞拍场景中。

2 原因分析

2.1 消息生产（Producer）远超预期

消息的生产的规模远超过原来的预期值，成数倍甚至几十倍的增长，这种产生的原因可能如下：

1. 比如遇到各种流量冲击的活动：618、双11大促、竞拍、抢购、秒杀业务。（这种需要做好容量预估管理）
2. 程序缺陷；死循环调用、批量请求、内存泄漏导致的流量飙升问题。（这种需要做好）

2.2 消息接收和持久化出现故障

Broker服务器接收消息并持久化出现问题：服务故障、网络延迟、持久化失败等，这种情况一般也比较少见…

2.3 消息消费（Consumer）能力下降致消息堆积

出现原因可能有如下几种：

• 消费失败时大量重试导致消息堆积。
• 消费者程序的故障：如 程序死锁，io阻塞等。
• 消费者资源瓶颈：目前的主流消息队列，单个节点消息收发的性能可以达到万级别甚至10万级+的水平。除非容量预估没有做好，一般不会出现这种问题。即使出现这种问题，通过Scale Out Broker 的实例数也是比较轻松可以解决的。

3 消息堆积的解决方案

根据上面的整理，在遇到消息堆积的时候，先检查下导致堆积的原因，看符合上述的三个原因的哪一个。

• 消息生产（Producer）远超预期
• 消息接收和持久化出现故障
• 消息消费（Consumer）能力下降致消息堆积

找到原因之后，把问题处理完成，然后临时扩容，来处理堆积的消息数据。具体操作步骤如下，参考下面的图：

• 先分析原因，如果是Consumer或者Broker出现故障要先确保恢复故障；如果是消息消费问题，先修复程序问题。
• 暂停现有Consumer的消费动作。
• 临时建立好原先10倍（或者N倍）的queue数量，即新建topic，partition分区是原来的10倍。
• 写一个程序，这个程序只做简单的转发工作，目的就是将消费积压的消息，均匀的消费到临时扩容好的queue里（这里面有10倍的容量）。
• Consumer也扩容10倍，对应一个Consumer消费一个临时的Queue。相应的被消费者依赖的业务处理服务也需要对应的扩容，包含缓存、数据库、文件服务等等。
• 快速消费结束之后，记得恢复原来的消费架构，避免大量资源浪费。

总结

本文介绍了消息堆积可能导致的原因，以及基本的处理步骤。大部分消息中间件的健壮性都是非常好的。
业务的不合理使用和扩展一般是主要诱因，所以平时需要多关注业务服务的变化。

为帮助开发者们提升面试技能、有机会入职BATJ等大厂公司，特别制作了这个专辑——这一次整体放出。

大致内容包括了： Java 集合、JVM、多线程、并发编程、设计模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat等大厂面试题等、等技术栈！

欢迎大家关注公众号【Java烂猪皮】，回复【666】，获取以上最新Java后端架构VIP学习资料以及视频学习教程，然后一起学习，一文在手，面试我有。

每一个专栏都是大家非常关心，和非常有价值的话题，如果我的文章对你有所帮助，还请帮忙点赞、好评、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！