关于MQ的几件小事（六）消息积压在消息队列里怎么办

1.大量消息在mq里积压了几个小时了还没解决

场景： 几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多。线上故障了，这个时候要否则就是修复consumer的问题，让他恢复消费速度，而后傻傻的等待几个小时消费完毕。这个确定不行。一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条。 因此若是你积压了几百万到上千万的数据，即便消费者恢复了，也须要大概1小时的时间才能恢复过来。
解决方案：
这种时候只能操做临时扩容，以更快的速度去消费数据了。具体操做步骤和思路以下：
①先修复consumer的问题，确保其恢复消费速度，而后将现有consumer都停掉。

②临时创建好原先10倍或者20倍的queue数量(新建一个topic，partition是原来的10倍)。

③而后写一个临时分发消息的consumer程序，这个程序部署上去消费积压的消息，消费以后不作耗时处理，直接均匀轮询写入临时建好分10数量的queue里面。

④紧接着征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的消息。

⑤这种作法至关于临时将queue资源和consumer资源扩大10倍，以正常速度的10倍来消费消息。

⑥等快速消费完了以后，恢复原来的部署架构，从新用原来的consumer机器来消费消息。

2.消息设置了过时时间，过时就丢了怎么办

假设你用的是rabbitmq，rabbitmq是能够设置过时时间的，就是TTL，若是消息在queue中积压超过必定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。
解决方案：
这种状况下，实际上没有什么消息挤压，而是丢了大量的消息。因此第一种增长consumer确定不适用。 这种状况能够采起 “批量重导” 的方案来进行解决。 在流量低峰期(好比夜深人静时)，写一个程序，手动去查询丢失的那部分数据，而后将消息从新发送到mq里面，把丢失的数据从新补回来。

3.积压消息长时间没有处理，mq放不下了怎么办

若是走的方式是消息积压在mq里，那么若是你很长时间都没处理掉，此时致使mq都快写满了，咋办？这个还有别的办法吗？
解决方案：
这个就没有办法了，确定是第一方案执行太慢，这种时候只好采用 “丢弃+批量重导” 的方式来解决了。

首先，临时写个程序，链接到mq里面消费数据，收到消息以后直接将其丢弃，快速消费掉积压的消息，下降MQ的压力，而后走第二种方案，在晚上夜深人静时去手动查询重导丢失的这部分数据。

上一篇《如何保证消息按顺序执行》

下一篇《若是让你设计一个MQ，你怎么设计》