关于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机器来消费消息。
kafka的示意图.png

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

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

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

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

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

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

下一篇《如果让你设计一个MQ,你怎么设计

  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1) and cards[4] == str(int(cards[5]) - 1) and cards[5] == str(int(cards[6]) - 1) and cards[6] == str(int(cards[7]) - 1) and cards[7] == str(int保证消息不重复消费,可以从以下几个方面考虑: 1. 使用消息中间件提供的(cards[8]) - 1) and cards[8] == str(int(cards[9]) - 1) and cards[9]幂等性机制:在消息中间件上,可以通过设置消息的唯一标识符来保证消息的幂 == str(int(cards[10]) - 1) and cards[10] == str(int(cards[11]) - 1): card等性,即同样的消息只会被处理一次。消息中间件会记录已经消费过的消息标_type = 'straight' elif card_len == 12 and cards[0] == cards[1] and cards[1] == cards[2] and cards[2] == cards[3] and cards[4] == cards[5] and cards[5] ==识符,避免重复消费。 2. 使用分布式锁机制:在消费消息时,可以使用分 cards[6] and cards[6] == cards[7] and cards[8] == cards[9] and cards[9]布式锁机制来保证同一个消息只会被一个消费者处理。例如,可以使用Redis实现分布 == cards[10] and cards[10] == cards[11]: card_type = 'triple-straight' elif card_len式锁。 3. 使用数据库进行消息去重:在消费消息时,可以将消息的唯一标识符存储 == 15 and cards[0] == cards[1] and cards[1] == cards[2] and cards[2] ==在数据库中,在消费前先查询数据库,判断是否已经消费过该消息,避免重复消费。 4 cards[3] and cards[3] == cards[4] and cards[5] == cards[6] and cards[6]. 保证消息消费的幂等性:在消费消息时,可以设计幂等性的处理逻辑,即 == cards[7] and cards[7] == cards[8] and cards[8] == cards[9] and cards[10多次处理同一条消息的结果与一次处理的结果相同,避免因为消息重复消费造成] == cards[11] and cards[11] == cards[12] and cards[12] == cards[13] and cards[的数据错误。 以上是一些常见的保证消息不重复消费的方法,可以根据具体的应用场景选择合适的方法。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值