完了!生产事故!几百万消息在消息队列里积压了几个小时!

作者:中华石杉

来源:https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/mq-time-delay-and-expired-failure.md

一、面试题

如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?

二、面试官心里分析

你看这问法,其实本质针对的场景,都是说,可能你的消费端出了问题,不消费了,或者消费的极其极其慢。接着就坑爹了,可能你的消息队列集群的磁盘都快写满了,都没人消费,这个时候怎么办?或者是整个这就积压了几个小时,你这个时候怎么办?或者是你积压的时间太长了,导致比如rabbitmq设置了消息过期时间后就没了怎么办?

所以就这事儿,其实线上挺常见的,一般不出,一出就是大case,一般常见于,举个例子,消费端每次消费之后要写mysql,结果mysql挂了,消费端hang那儿了,不动了。或者是消费端出了个什么叉子,导致消费速度极其慢。

三、面试题分析

关于这个事儿,我们一个一个来梳理吧,先假设一个场景,我们现在消费端出故障了,然后大量消息在mq里积压,现在事故了,慌了

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

几千万条数据在MQ里积压了七八个小时,从下午4点多,积压到了晚上很晚,10点多,11点多。

这个是我们真实遇到过的一个场景,确实是线上故障了,这个时候要不然就是修复consumer的问题,让他恢复消费速度,然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。

一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条。

所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来。

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

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

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

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

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

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

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

2、这里我们假设再来第二个坑

假设你用的是rabbitmq,rabbitmq是可以设置过期时间的,就是TTL,如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉,这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里,而是大量的数据会直接搞丢。

这个情况下,就不是说要增加consumer消费积压的消息,因为实际上没啥积压,而是丢了大量的消息。我们可以采取一个方案,就是批量重导,这个我们之前线上也有类似的场景干过。就是大量积压的时候,我们当时就直接丢弃数据了,然后等过了高峰期以后,比如大家一起喝咖啡熬夜到晚上12点以后,用户都睡觉了。

这个时候我们就开始写程序,将丢失的那批数据,写个临时程序,一点一点的查出来,然后重新灌入mq里面去,把白天丢的数据给他补回来。也只能是这样了。

假设1万个订单积压在mq里面,没有处理,其中1000个订单都丢了,你只能手动写程序把那1000个订单给查出来,手动发到mq里去再补一次。

3、然后我们再来假设第三个坑

如果走的方式是消息积压在mq里,那么如果你很长时间都没处理掉,此时导致mq都快写满了,咋办?这个还有别的办法吗?没有,谁让你第一个方案执行的太慢了,你临时写程序,接入数据来消费,消费一个丢弃一个,都不要了,快速消费掉所有的消息。然后走第二个方案,到了晚上再补数据吧。

另外,大家有什么好的想法,欢迎留言补充哦!

热门内容:

1、为什么阿里巴巴不建议在for循环中使用"+"进行字符串拼接?

2、IDEA已经18岁了!这个好用的插件应该告诉你了!

3、GitHub竟然还可以这样玩?涨知识了!

4、阿里分布式事务框架GTS开源啦!

5、程序员:平时的你 vs 面试的你!

6、一场近乎完美基于Dubbo的微服务改造实践

7、你还在 SELECT * 吗?

8、困扰多年的Java泛型解惑之 extends T>和 super T>

原文地址:https://www.cnblogs.com/xuliugen/p/10420770.html

时间: 2024-07-31 11:16:27

完了!生产事故!几百万消息在消息队列里积压了几个小时!的相关文章

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

1.大量消息在mq里积压了几个小时了还没解决 场景:几千万条数据在MQ里积压了七八个小时,从下午4点多,积压到了晚上很晚,10点多,11点多.线上故障了,这个时候要不然就是修复consumer的问题,让他恢复消费速度,然后傻傻的等待几个小时消费完毕.这个肯定不行.一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条. 所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来. 解决方案:" 这种时候只能操作临时扩容,以更快的速

【转】windows消息和消息队列详解

转载出处:http://blog.csdn.net/bichenggui/article/details/4677494  windows消息和消息队列 与基于MS - DOS的应用程序不同,Windows的应用程序是事件(消息)驱动的.它们不会显式地调用函数(如C运行时库调用)来获取输入,而是等待windows向它们传递输入. windows系统把应用程序的输入事件传递给各个窗口,每个窗口有一个函数,称为窗口消息处理函数.窗口消息处理函数处理各种用户输入,处理完成后再将控制权交还给系统.窗口消

rabbitmq之消息重入队列

说起消息重入队列还得从队列注册消费者说起,客户端在向队列注册消费者之后,创建的channel也会被主队列进程monitor,当channel挂掉后,主队列进程(rabbit_amqqueue_process)收到'DOWN'通知,将未ack的消息重入队列,并根据消息的deliver tag,也就是消费入队列的顺序,将消息重入队列中 主要代码如下: 1.注册消费者 handle_method(#'basic.consume'{queue = QueueNameBin, consumer_tag =

发送消息 MFC 消息映射

发送消息 MFC 消息映射 (2011-07-11 17:03:49) 转载▼ 标签: 发送消息 mfc 消息映射 杂谈   1.在用WIN 32 API函数开发应用程序时,经常要用SendMassege函数向某些对象发送消息,以让对象实现某些功能(此时也有相应的API 函数来实现这个功能).例如关闭窗口,可以发送WM_CLOSE消息.SendMessage(hwnd,WM_SYSCOMMAND,SC_CLOSE,0);//关闭主窗口SendMessage(hwnd,WM_CLOSE,0,0);

关于windows操作系统之消息和消息队列

关于消息和消息队列 不像基于MS-DOS的应用程序,基于Windows的程序是事件驱动的.他们不做任何显示调用来获取输入.而是通过等待系统传递给他们. 系统为应用程序传递所有输入到程序中的不同窗口.每个窗口都有一个称为窗口过程的函数,用于处理所有到该窗口的输入.窗口处理过程处理输入,并将控制返回给系统. 如果一个顶层窗口停止响应消息超过两秒,系统将会认为该窗口为非响应状态.在这种情况下,系统将隐藏该窗口并用拥有同样Z顺序,位置,尺寸和可视化属性的ghost窗口替代该窗口.这种情况下,允许用户移动

RabbitMq+Spring boot 消息生产者向队列发送消息 (一)

本人学习新框架方法. 一.先学习框架基本知识,也就是看这本书的前三章,了解基本概念.比如这个Rabbitmq,我会先看一些概念,比如,交换机,路由器,队列,虚拟机. 二.然后写代码,写demo,有哪些不懂的地方直接再去翻书或者google找资料,带着问题去学习,学的更快更扎实一些. 三.然后再看这个框架的应用场景,自己能否独立的写一些简单的项目,来验证自己的成果. 四.实际项目积累经验. RabbitMq 消息生产者向队列发送消息 (一) MQ分为消息生产者和消息消费者,这次做的主要是消息的生产

因我而起的生产事故

首先,祝大家新年快乐!应该陆陆续续开始踏上了回家的征程吧! 生产事故 产品上线一段时间之后,技术支持反馈客户现场一个进程总是挂掉或者不干活!最开始不紧不慢的查找问题,后来老大很生气说:生产事故很严重,你们居然不重视!成立了一个应急小组,专门解决此问题,其中包括我! 事故原因 经过2.3天没日没夜的艰苦奋斗,终于找到进程挂掉的原因,问题因我而起.大约去年8月,做一个项目,与大数据对接,把数据推给它,然在加上了推送部分的代码,最开始那个模块是没有日志的,然后给加上了日志打印,当时也没考虑那么多,多线

生产事故(MongoDB数据分布不均解决方案)

可以很明显可以看到我们这个集合的数据严重分布不均匀. 一共有8个分片,面对这个情况我首先想到的是手动拆分数据块,但这不是解决此问题的根本办法. 造成此次生产事故的首要原因就是片键选择上的问题,由于片键选择失误,在数据量级不大的时候数据看起来还是很健康的,但随着数据量的暴涨,问题就慢慢浮出了水面,我们使用的组合片键并不是无规律的,片键内容是线性增长的,这就导致了数据的不正常聚集.由于数据分布不均匀,我们有两个分片的磁盘使用率接近80%,数据还在持续增长,这个问题必须尽快解决. 涉及到此次事故的集合

设计一个百万级的消息推送系统

原文链接:https://crossoverjie.top/2018/09/25/netty/million-sms-push/ 前言 首先迟到的祝大家中秋快乐. 最近一周多没有更新了.其实我一直想憋一个大招,分享一些大家感兴趣的干货. 鉴于最近我个人的工作内容,于是利用这三天小长假憋了一个出来(其实是玩了两天??). 先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互. 最主要的工作就是要有一个系统来支持设备的接入.向设备推送消息:同时还得满足大量设备接入