常见面试题,消息堆积了怎么办?

猿天地

共 1407字,需浏览 3分钟

 ·

2022-07-09 19:32


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



大家好,我是【架构摆渡人】,一只十年的程序猿。这是消息队列的第八篇文章,这个系列会给大家分享很多在实际工作中有用的经验,如果有收获,还请分享给更多的朋友。
 
这个问题在面试中出现的概率极高,这也是面试官考察你是否在工作中有过实际解决问题的能力。当然也不一定每个人都能遇到这个问题,即使遇不到,我们也要对这些问题的解决方式了然于胸。
 
如果你被问到这个问题,可以从两个方面来回答。一个是前置的预防,另一个是发生后的处理过程。
 


前置预防




前置预防,我们需要有强大的监控体系。当某个Topic中消息堆积的量到达一定程度,那么此时要能够及时告警,早点介入进去。
 
另一个就是平时要监控消费的速度和耗时,如果消费耗时突然变高了,也要及时关注,有可能是因为迭代的过程中不断的加逻辑,没有进行优化,导致处理时间越来越长。处理时间变长,那么也就意味着消费的吞吐量会下降。
 
其次,还需要监控消息的发送方速度,平时发送的TPS也就1000左右,能够被正常消费,几乎没有消息堆积。但是有天突然消息的发送TPS慢慢的增长了5000,此时必然消费不过来,随着时间的推移,消息必然出现堆积情况。

过程处理





消息可丢弃

对于消息可以丢弃的处理方式非常简单,一般有2种方式。
 
第一种:消费的代码中增加一个开关,当开关开启的时候不进行业务逻辑的处理,这样相当于消费的RT是0ms,堆积的消息很快就会被消费完的。然后再把开关关掉,开始正常的消费逻辑。
 
第二种:利用MQ自带的功能,重置消费点的位置。一般都是可以基于时间来进行重置,你可以直接重置到当前的这一分钟,也就是当前时间之前的消息都会被跳过,这样也能快速恢复正常的消费。

 

消息不能丢

对于消息不能丢的场景,只能从消费速度去提升了,这样才能尽快将堆积的消息消费掉。
 
第一种:增加消费线程数量,让消费尽可能并发处理,但是一定得考虑消费逻辑的问题,如果消费逻辑里面是对数据库进行操作,那么得看数据库的性能是否能够扛住这些并发,否则数据也需要临时进行扩容。
 
第二种:如果每个消费的线程数已经很大了,这个时候需要对消费者的节点进行扩容了。说白了就是之前10个人在搬砖,现在多加10个人,速度自然就上来了。
 
但是搬砖也是有规矩的,就是整个工地会划分为多个块,每个人负责搬一个块,如果只有15个块,即使有20个人也没办法加速,所以要把块分多一点,让每个人都能搬一个块这样效率才会高。
 
同理,在MQ中一个Topic的消息会存储在多个Queue中,一个Queue只会被一个消费者消费,所以如果增加消费者之后速度还是上不来,就需要新建一个Queue数量多的Topic来接收之前堆积的消息,这样加大消费者数量才能提高消费速度。

 

总结




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

 

原创:架构摆渡人(公众号ID:jiagoubaiduren),欢迎分享,转载请保留出处。

 


浏览 16
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报