分布式进阶（六）——分布式框架之高性能：消息积压

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

 

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

 

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

一、消息积压

消息积压，就是说消息队列里面积压了大量消息，一般是由于生产者投递消息的速率远远大于消息者消费消息的速率。比如消费者端程序挂掉，或者吞吐量变得极小，此时，MQ集群的磁盘可能会很快被写满。

消息积压问题本身很容易理解，解决这个问题的根本思路是 如何在出现消息积压时快速将积压的消息处理掉 。比如下图中的情况：
一个消费者1秒消费1000条消息，那3个消费者1s就消费3000条，所以如果你积压了几百万甚至上千万的消息，即使消费者恢复了，也需要大概1小时的时间才能消费完。

所以，要让积压的消息能被快速消费掉，仅仅靠原来的几个消费者去消费是不够的，我们必须提升消费速率。

二、解决方案

如果生产上出现上述的情况，即MQ里积压了成百上千万的消息，那基本上只能 临时紧急扩容 了，具体操作步骤和思路如下：

1. 先修复消息者端的程序问题，然后将现有consumer全部停掉；
2. 新建一个Topic，partition是原来的10倍（如果是使用RabbitMQ，则临时建立原先10倍/20倍的queue数量）；
3. 写一个临时分发数据的consumer程序，将这个程序部署上去消费积压的数据，消费之后不做任何处理而是直接轮询写入上述临时建立好的queue；
4. 临时征用10倍的机器来部署原来步骤1中停掉的consumer，每一批consumer消费一个临时queue的数据；

这种解决方案相当于临时将queue资源和consumer资源扩大10倍，以10倍于正常的速度去消费数据，等快速消费完积压消息之后，再恢复原先的部署。

2.1 磁盘问题

还有一个问题：如果消息大量积压在MQ里，导致磁盘快写满了咋办？

这种情况很可能是系统规划时没有合理分配磁盘资源，没考虑到消息积压的异常场景，并没有很好的解决办法，为了保证正常业务不受影响，可以采用以下方案：

临时写个程序，不断去消费积压的消息， 消费一个丢弃一个，都不要了 ，目的是快速消费掉所有的消息，避免磁盘撑爆导致系统没法正常运行，然后走上述的临时紧急扩容方案，等系统正常后晚上再进行数据重发，补数据。