RocketMQ - 如何处理消费系统故障导致RocketMQ消息积压问题？_rocketmq故障处理机制

先来介绍一个比较真实的生产场景，我们曾经有一个消息中心系统，他就是由生产者系统和消费者系统两个环节组成的，生产者系统会负责不停的把消息写入RocketMQ里去，然后消费者系统就是负责从RocketMQ里消费消息。

这个系统在生产环境是有高峰和低谷的，在晚上几个小时的高峰期内，大概就会有几十万条消息进入RocketMQ。然后消费者系统从RocketMQ里获取到消息之后，会依赖一些NoSQL数据库去进行一些业务逻辑的实现。

然后有一天晚上就出现了一个问题，消费者系统依赖的NoSQL数据库就挂掉了，导致消费者系统自己也没法运作了，此时就没法继续从RocketMQ里消费数据和处理了，消费者系统几乎就处于停滞不动的状态。

然后生产者系统在晚上几个小时的高峰期内，就往MQ里写入了100多万的消息，此时都积压在MQ里了，根本没人消费和处理。

针对这种紧急的线上事故，一般来说有几种方案可以快速搞定它，如果这些消息你是允许丢失的，那么此时你就可以紧急修改消费者系统的代码，在代码里对所有的消息都获取到就直接丢弃，不做任何的处理，这样可以迅速的让积压在MQ里的百万消息被处理掉，只不过处理方式就是全部丢弃而已。

但是往往对很多系统而言，不能简单粗暴的丢弃这些消息，所以最常见的办法，还是先等待消费者系统底层依赖的NoSQL数据库先恢复了，恢复之后，就可以根据你的线上Topic的MessageQueue的数量来看看如何后续处理。

假如你的Topic有20个MessageQueue，然后你只有4个消费者系统在消费，那么每个消费者系统会从5个MessageQueue里获取消息，所以此时如果你仅仅依靠4个消费者系统是肯定不够的，毕竟MQ里积压了百万消息了。

所以此时你可以