常见面试题，消息堆积了怎么办？-技术圈

点击上方蓝字“设为星标”

大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第八篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

这个问题在面试中出现的概率极高，这也是面试官考察你是否在工作中有过实际解决问题的能力。当然也不一定每个人都能遇到这个问题，即使遇不到，我们也要对这些问题的解决方式了然于胸。

如果你被问到这个问题，可以从两个方面来回答。一个是前置的预防，另一个是发生后的处理过程。

前置预防

前置预防，我们需要有强大的监控体系。当某个Topic中消息堆积的量到达一定程度，那么此时要能够及时告警，早点介入进去。

另一个就是平时要监控消费的速度和耗时，如果消费耗时突然变高了，也要及时关注，有可能是因为迭代的过程中不断的加逻辑，没有进行优化，导致处理时间越来越长。处理时间变长，那么也就意味着消费的吞吐量会下降。

其次，还需要监控消息的发送方速度，平时发送的TPS也就1000左右，能够被正常消费，几乎没有消息堆积。但是有天突然消息的发送TPS慢慢的增长了5000，此时必然消费不过来，随着时间的推移，消息必然出现堆积情况。

过程处理

对于消息可以丢弃的处理方式非常简单，一般有2种方式。

第一种：消费的代码中增加一个开关，当开关开启的时候不进行业务逻辑的处理，这样相当于消费的RT是0ms，堆积的消息很快就会被消费完的。然后再把开关关掉，开始正常的消费逻辑。

第二种：利用MQ自带的功能，重置消费点的位置。一般都是可以基于时间来进行重置，你可以直接重置到当前的这一分钟，也就是当前时间之前的消息都会被跳过，这样也能快速恢复正常的消费。

对于消息不能丢的场景，只能从消费速度去提升了，这样才能尽快将堆积的消息消费掉。

第一种：增加消费线程数量，让消费尽可能并发处理，但是一定得考虑消费逻辑的问题，如果消费逻辑里面是对数据库进行操作，那么得看数据库的性能是否能够扛住这些并发，否则数据也需要临时进行扩容。

第二种：如果每个消费的线程数已经很大了，这个时候需要对消费者的节点进行扩容了。说白了就是之前10个人在搬砖，现在多加10个人，速度自然就上来了。

但是搬砖也是有规矩的，就是整个工地会划分为多个块，每个人负责搬一个块，如果只有15个块，即使有20个人也没办法加速，所以要把块分多一点，让每个人都能搬一个块这样效率才会高。

同理，在MQ中一个Topic的消息会存储在多个Queue中，一个Queue只会被一个消费者消费，所以如果增加消费者之后速度还是上不来，就需要新建一个Queue数量多的Topic来接收之前堆积的消息，这样加大消费者数量才能提高消费速度。

总结

导致消息堆积的原因有很多，我们需要沉着冷静的去分析为是什么原因导致了消息堆积。是消费速度慢导致的，还是消费速度挺快，但是生产速度太快了，实在是更不上导致的，还是说MQ的重平衡逻辑有bug导致某些Queue没有被消息产生的堆积。我们只有了解了背后的原因才能选择合适的解决方案。

原创：架构摆渡人（公众号ID：jiagoubaiduren），欢迎分享，转载请保留出处。