参考答案
1 如何确定RocketMQ有大量的消息积压？
在正常情况下，使用 MQ 都会要尽量保证：他的消息生产速度和消费速度整体上是平衡的。
如果部分消费者系统出现故障，就会造成大量的消息积累。
在实际工作中，这类问题出现得较为隐蔽。
例如：
某天一个数据库突然挂了，我们大概率就会集中处理数据库的问题。好不容易把数据库恢复了，这时，基于这个数据库服务的消费者程序就会积累大量的消息，或者因为网络波动等导致消息大量的积累。
在一些大型的互联网项目中，消息积压的速度是相当恐怖的。所以，消息积压是个需要时时关注的问题。
RocketMQ 或 Kafka 的消息积压，不会对性能造成很大的影响， RabbitMQ 的大量的消息积压，就可以瞬间造成性能直线下滑。
对于 RocketMQ 来说，有个最简单的方式来确定消息是否有积压。那就是使用 web 控制台，就能直接看到消息的积压情况。 在 Web 控制台的主题页面，可以通过 Consumer 管理按钮，实时看到消息的积压情况。
另外，
也可以通过 mqadmin 指令，在后台检查各个 Topic 的消息延迟情况。
还有 RocketMQ 也会在它的 ${storePathRootDir}/config 目录下，落地一系列的 json 文件，用来跟踪消息积压情况。
2 如何处理大量积压的消息？
如果 Topic 下的 MessageQueue 配置足够多，那每个 Consumer 就会分配多个 MessageQueue 来进行消费。
此时，就可以简单的通过增加 Consumer 的服务节点数量，来加快消息的消费，等积压消息消费完了，再恢复正常。
最极限的情况：是把 Consumer 的节点个数，设置成跟 MessageQueue 的个数相同。此时再继续增加 Consumer 的服务节点，就没有作用了。
如果 Topic下 的 MessageQueue 配置不够多，那就不能用上面这种增加 Consumer 节点个数的方法了。
这个时候怎么办呢？
要快速处理积压的消息，我们可以创建一个新的 Topic，配置足够多的 MessageQueue，把所有消费者节点的目标 Topic ，转向新的 Topic ，并紧急上线一组新的消费者，只负责消费旧 Topic 中的消息，并转储到新的 Topic 中，这个速度是可以很快的。在新的 Topic 上，可以通过增加消费者个数提高消费速度，再恢复正常。
在官网中，还分析了一个特殊的情况，如果 RocketMQ 原本采用的是普通方式搭建主从架构，现在想要中途改为使用 Dledger 高可用集群，这时候如果不想历史消息丢失，就要先将消息进行对齐，也就是要消费者把所有的消息都消费完，再来切换主从架构。
因为，Dledger 集群会接管 RocketMQ 原有的 CommitLog 日志，所以切换主从架构时，如果有消息没有消费完，这些消息是存在旧的CommitLog中的，就无法再进行消费了，这个场景下，也是需要尽快的处理掉积压的消息。
以上，是消息队列 RocketMQ 面试题【使用 RocketMQ，如何快速处理积压消息？】的参考答案。
输出，是最好的学习方法。
欢迎在评论区留下你的问题、笔记或知识点补充~
—end—
