这篇文章，我们聊聊如何应对 RocketMQ 消息堆积。
消费者在消费的过程中，消费的速度跟不上服务端的发送速度，未处理的消息会越来越多，消息出现堆积进而会造成消息消费延迟。
虽然笔者经常讲：RocketMQ 、Kafka 具备堆积的能力，但是以下场景需要重点关注消息堆积和延迟的问题：
-
业务系统上下游能力不匹配造成的持续堆积，且无法自行恢复。
-
业务系统对消息的消费实时性要求较高，即使是短暂的堆积造成的消息延迟也无法接受。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
-
视频教程：https://doc.iocoder.cn/video/
客户端使用
Push 模式
启动后，消费消息时，分为以下两个阶段：
-
阶段一：
拉取消息
客户端通过长轮询批量拉取的方式从 Broker 服务端获取消息，将拉取到的消息缓存到本地缓冲队列中。
客户端批量拉取消息，常见内网环境下都会有很高的吞吐量，例如：1个单线程单分区的低规格机器（4C8GB）可以达到几万 TPS ，如果是多个分区可以达到几十万 TPS 。所以这一阶段一般不会成为消息堆积的瓶颈。
-
阶段二：
消费消息
提交消费线程，客户端将本地缓存的消息提交到消费线程中，使用业务消费逻辑进行处理。
此时客户端的消费能力就完全依赖于业务逻辑的复杂度（
消费耗时
）和消费逻辑
并发度
了。如果业务处理逻辑复杂，处理单条消息耗时都较长，则整体的消息吞吐量肯定不会高，此时就会导致客户端本地缓冲队列达到上限，停止从服务端拉取消息。
通过以上客户端消费原理可以看出，消息堆积的主要瓶颈在于本地客户端的消费能力，即
消费耗时
和
消费并发度
。
想要避免和解决消息堆积问题，必须合理的控制消费耗时和消息并发度，其中消费耗时的优先级高于消费并发度，必须先保证消费耗时的合理性，再考虑消费并发度问题。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
-
视频教程：https://doc.iocoder.cn/video/
影响消费耗时的消费逻辑主要分为 CPU 内存计算和外部 I/O 操作，通常情况下代码中如果没有复杂的递归和循环的话，内部计算耗时相对外部 I/O 操作来说几乎可以忽略。
外部 I/O 操作通常包括如下业务逻辑：
