线上百万MQ消息积压的快速处理方案

在我们日常的生产环境上，由于某些原因（如消费者代码中bug、消费者端使用的中间件存在性能问题）导致消费者不能处理消息或者消费者处理速度极慢进而导致了线上出现百万的消息积压。

    假设现在存在百万消息在消息队列中堆积，我们如何快速的消费完这些消息呢？

1、优化消费者的代码

    由于消费者现在是消费速度不够导致了MQ消息的积压，所以我们可以将消费的代码做优化（如减少业务中不必要的计算，采用多线程的方式消费等等）来提高消费者的速度。

    假设消费者机器有两台，代码优化前是200条/秒的消费速度，代码优化后消费者的消费速度提到了400条/秒；这样的两台机器1小时可以消费消息条数是：400*60*60*2=2880000条/小时，所以百万消息的积压预估是需要1小时才可以完成消费完成。线上一些特殊的业务是不允许这样的时间延迟。

2、新建临时topic

    假设原先topic是两个分区，消费者消费消息的业务逻辑中有数据持久化等相对耗时的操作。

    由于MQ中有大量的消息积压，为此我们将消费者的代码做一些调整，即就是消费者不做实际的业务处理，而是将消息转发到临时的topic中（temp_topic），并且在临时的topic中增加是原来若干倍（如设置成原来的10倍）的分区

    然后增加临时的机器来消费临时topic上的消息，将原先的业务逻辑放在临时的消息中完成。

    等MQ（topic1）中的消息被快速消费完之后将不在向临时的topic中转发消息并且临时的消费者机器下掉，继续执行原下的逻辑。

本方案要注意如下几点：

（1）增了临时topic分区和临时消费者机器，数据库可能会承受不了压力而导致崩溃，所以最好要做一些数据库保护措施。

（2）针对一些设置了失效时间的MQ消息，由于积压在MQ队列中时间过长导致消息失效了。为了保证数据不丢失，我们需要手动处理业务数据（如通过定时任务的方式将数据失效的MQ消息再重新发送一次）。

（3）消息积压也可能会导致某些分区无法再存储新生产的消息，导致消息丢失。针对这样的业务我们也需要手动地处理业务。

是否只增加消费者机器而不做分区的扩容呢？

   现在由于性能的瓶颈在MQ的分区上，即使增加了消费者机器消费的速度还是很慢的。

总结：

    针对线上MQ消息大量积压的问题，我们首先要做好消息积压到一定量之后做告警措施（如发短信或者邮件通知给负责人），然后排查和解决消费者问题（如修复消费者的bug或者消费者端消费的性能瓶颈问题），如果还存在大量的消息积压的问题，最后再采用新建临时topic的方式去快速消费积压的消息。