1. 快速处理积压的消息

1.1 确认消息积压

1. 在Web控制台的主题页面，可以通过 查看Topic下的Consumer管理按钮实时看到消息的积压情况。

2. 也可以通过mqadmin指令在后台检查各个Topic的消息延迟情况。
3. 有RocketMQ也会在他的 ${storePathRootDir}/config 目录下落地一系列的json文件，也可以用来跟踪消息积压情况。

1.2 解决消息积压

1. 如果Topic下的MessageQueue配置得是足够多的，那每个Consumer实际上会分配多个MessageQueue来进行消费。这个时候，就可以简单的通过增加Consumer的服务节点数量来加快消息的消费，等积压消息消费完了，再恢复成正常情况。最极限的情况是把Consumer的节点个数设置成跟MessageQueue的个数相同。但是如果此时再继续增加Consumer的服务节点就没有用了。
2. 而如果Topic下的MessageQueue配置得不够多的话，那就不能用上面这种增加Consumer节点个数的方法了。这时如果要快速处理积压的消息：
   1. 可以创建一个新的Topic，配置足够多的MessageQueue；
   2. 然后把所有消费者节点的目标Topic转向新的Topic；
   3. 并紧急上线一组新的消费者，只负责消费旧Topic中 的消息，并转储到新的Topic中，这个速度是可以很快的。
   4. 然后在新的Topic上，就可以通过增加消费者个数来提高消费速度了。

1.3 架构切换问题

在官网中，还分析了一个特殊的情况。就是如果RocketMQ原本是采用的普通方式搭建主从架构，而现在想要中途改为使用Dledger高可用集群，这时候如果不想历史消息丢失，就需要先将消息进行对齐，也就是要消费者把所有的消息都消费完，再来切换主从架构。因为Dledger集群会接管RocketMQ原有的CommitLog日志，所以切换主从架构时，如果有消息没有消费完，这些消息是存在旧的CommitLog中的，就无法再进行消费了。这个场景下也是需要尽快的处理掉积压的消息。