如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?

思考


  1. 是什么导致了消息积压?是consumer程序bug?是consumer消费的速度落后于消息生产的速度?
  2. 积压了多长时间,积压了多少量?
  3. 对业务的影响?

解决思路

1. 如果仅仅是consumer消费的速度落后于消息生产的速度的话,可以考虑采用扩容消费者群组的方式。
2. 如果积压比较严重,积压了上百万、上千万的消息。

  1. 修复现有consumer的问题,并将其停掉。
  2. 重新创建一个容量更大的topic,比如patition是原来的10倍。
  3. 编写一个临时consumer程序,消费原来积压的队列。该consumer不做任何耗时的操作,将消息均匀写入新创建的队列里。
  4. 将修复好的consumer部署到原来10倍的机器上消费新队列。
  5. 消息积压解决后,恢复原有架构。

3. 如果消息已经丢失

由于有的消息队列有过期失效的机制,造成了大量的消息丢失。

这种情况只能将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入mq里面去。 




 消息积压---一般处理方法_数据库


 



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

  几千万条数据在MQ里积压了七八个小时,最简单的方法可以让他恢复消费速度,然后等待几个小时消费完毕。 

  一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条 ,所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来  

  一般这个时候,只能操作临时紧急扩容了,具体操作步骤和思路如下:  

    先修复consumer的问题,确保其恢复消费速度,然后将现有cnosumer都停掉

    新建一个topic,partition是原来的10倍,临时建立好原先10倍或者20倍的queue数量

    然后写一个临时的分发数据的consumer程序,这个程序部署上去消费积压的数据,消费之后不做耗时的处理,直接均匀轮询写入临时建立好的10倍数量的queue

    接着临时征用10倍的机器来部署consumer,每一批consumer消费一个临时queue的数据

    这种做法相当于是临时将queue资源和consumer资源扩大10倍,以正常的10倍速度来消费数据

    等快速消费完积压数据之后,得恢复原先部署架构,重新用原先的consumer机器来消费消息


topic ---- kafka


数据库 ---- ES


 


 


参考: