关于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,你怎么设计

原文地址:https://www.cnblogs.com/jack1995/p/10908818.html

时间: 2024-07-30 01:57:51

关于MQ的几件小事(六)消息积压在消息队列里怎么办的相关文章

关于MQ的几件小事(七)如果让你设计一个MQ,你怎么设计

其实回答这类问题,说白了,起码不求你看过那技术的源码,起码你大概知道那个技术的基本原理,核心组成部分,基本架构构成,然后参照一些开源的技术把一个系统设计出来的思路说一下就好 比如说这个消息队列系统,我们来从以下几个角度来考虑一下 (1)首先这个mq得支持可伸缩性吧,就是需要的时候快速扩容,就可以增加吞吐量和容量,那怎么搞?设计个分布式的系统呗,参照一下kafka的设计理念,broker -> topic -> partition,每个partition放一个机器,就存一部分数据.如果现在资源不

关于MQ的几件小事(四)如何保证消息不丢失

1.mq原则 数据不能多,也不能少,不能多是说消息不能重复消费,这个我们上一节已解决:不能少,就是说不能丢失数据.如果mq传递的是非常核心的消息,支撑核心的业务,那么这种场景是一定不能丢失数据的. 2.丢失数据场景 丢数据一般分为两种,一种是mq把消息丢了,一种就是消费时将消息丢了.下面从rabbitmq和kafka分别说一下,丢失数据的场景, (1)rabbitmq A:生产者弄丢了数据 生产者将数据发送到rabbitmq的时候,可能在传输过程中因为网络等问题而将数据弄丢了. B:rabbit

关于MQ的几件小事(二)如何保证消息队列的高可用

1.RabbitMQ的高可用 RabbitMQ基于主从模式实现高可用.RabbitMQ有三种模式:单机模式,普通集群模式,镜像集群模式. (1)单机模式: 单机模式就是demo级别的,生产中不会有人使用. (2)普通集群模式 普通集群模式就是在多台机器上启动多个rabbitmq实例,每个机器启动一个.但是创建的queue只会放在一个rabbitmq实例上面,但是其他的实例都同步了这个queue的元数据.在你消费的时候,如果连接到了另一个实例,他会从拥有queue的那个实例获取消息然后再返回给你.

关于MQ的几件小事(一)消息队列的用途、优缺点、技术选型

1.为什么使用消息队列? (1)解耦:可以在多个系统之间进行解耦,将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯,只要该操作不是需要同步的,就可以改为使用MQ进行不同系统之间的联系,这样项目之间不会存在耦合,系统之间不会产生太大的影响,就算一个系统挂了,也只是消息挤压在MQ里面没人进行消费而已,不会对其他的系统产生影响. (2)异步:加入一个操作设计到好几个步骤,这些步骤之间不需要同步完成,比如客户去创建了一个订单,还要去客户轨迹系统添加一条轨迹.去库存系统更新库存.去客户系统修改

关于MQ的几件小事(三)如何保证消息不重复消费

1.幂等性 幂等(idempotent.idempotence)是一个数学与计算机学概念,常见于抽象代数中. 在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同.幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数.这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变.例如,"setTrue()"函数就是一个幂等函数,无论多次执行,其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 简单来说,幂等性就是一个数据

关于redis的几件小事(六)redis的持久化

1.redis持久化的意义 redis持久化的意义,在于 故障恢复 . 如果没有对数据进行持久化,那么如果redis遇到灾难性的故障,就会丢失所有的数据. 如果通过redis的持久化机制将数据持久化到硬盘上面去,然后在定期将磁盘上的文件备份到一起其他的服务器上面(比如:云服务器),这样就可以保证即使redis遇到了灾难事故,也可以使用提前备份的文件对数据进行回复,之后丢失最近的一部分数据,而不会全部丢失数据. 2.redis的两种持久化方式 redis的持久化是跟高可用相关的.redis有两种持

消息队列mq总结(重点看,比较了主流消息队列框架)

转自:http://blog.csdn.net/konglongaa/article/details/52208273 http://blog.csdn.net/oMaverick1/article/details/51331004 https://yq.aliyun.com/articles/25385 https://www.zhihu.com/question/22480085/answer/23106407 http://frank1998819.iteye.com/blog/22788

K8s 从懵圈到熟练 – 镜像拉取这件小事

作者 | 声东 阿里云售后技术专家 导读:相比 K8s 集群的其他功能,私有镜像的自动拉取,看起来可能是比较简单的.而镜像拉取失败,大多数情况下都和权限有关.所以,在处理相关问题的时候,我们往往会轻松的说:这问题很简单,肯定是权限问题.但实际的情况是,我们经常为一个问题,花了多个人的时间却找不到原因.这主要还是我们对镜像拉取,特别是私有镜像自动拉取的原理理解不深.这篇文章,作者将带领大家讨论下相关原理. 顺序上来说,私有镜像自动拉取会首先通过阿里云 Acr credential helper 组

一件小事引发纯属自我的调节,于是有了这篇随笔

只能说今天运气差到极点了吧,也是因此,晚上十点半的现在的我也只能在word上把随笔先写好,等网好了再发出去. 原定的计划是先把周末的网页先写得差不多再直接睡觉的,结果先是PS运行不了,再是快把PS安装包下载完的时候网络又出问题了.弄来弄去结果就把心态搞炸了.在写这篇随笔的时候网络还是忽好忽坏,PS还是没有下下来.这么早就睡觉肯定是睡不着的,也是想借写随笔的过程来平复下烦躁的心情吧. 学习日近尾声,老师的节奏加快的同时,自己的节奏越发受到外界因素的影响,许久未曾谋面的烦躁又开始活跃起来了.而且由于