MQ消息积压,把我整吐血了

我之前在一家餐饮公司待过两年,每天中午和晚上用餐高峰期,系统的并发量不容小觑。为了保险起见,公司规定各部门都要在吃饭的时间轮流值班,防止出现线上问题时能够及时处理。

我当时在后厨显示系统团队,该系统属于订单的下游业务。

用户点完菜下单后,订单系统会通过发​​kafka​​消息给我们系统,系统读取消息后,做业务逻辑处理,持久化订单和菜品数据,然后展示到划菜客户端。

这样厨师就知道哪个订单要做哪些菜,有些菜做好了,就可以通过该系统出菜。系统自动通知服务员上菜,如果服务员上完菜,修改菜品上菜状态,用户就知道哪些菜已经上了,哪些还没有上。这个系统可以大大提高后厨到用户的效率。

图片

这一切的关键是消息中间件:kafka,如果它出现问题,将会直接影响到后厨显示系统的用户功能使用。

这篇文章跟大家一起聊聊,我们当时出现过的​​消息积压问题​​,希望对你会有所帮助。

1 第一次消息积压

刚开始我们的用户量比较少,上线一段时间,mq的消息通信都没啥问题。

随着用户量逐步增多,每个商家每天都会产生大量的订单数据,每个订单都有多个菜品,这样导致我们划菜系统的划菜表的数据越来越多。

在某一天中午,收到商家投诉说用户下单之后,在平板上出现的菜品列表有延迟。

厨房几分钟之后才能看到菜品。

我们马上开始查原因。

出现这种菜品延迟的问题,必定跟kafka有关,因此,我们先查看kafka。

果然出现了​​消息积压​​。

通常情况下,出现消息积压的原因有:

  1. mq消费者挂了。
  2. mq生产者生产消息的速度,大于mq消费者消费消息的速度。

我查了一下监控,发现我们的mq消费者,服务在正常运行,没有异常。

剩下的原因可能是:mq消费者消费消息的速度变慢了。

接下来,我查了一下划菜表,目前不太多只有几十万的数据。

看来需要优化mq消费者的处理逻辑了。

我在代码中增加了一些日志,把mq消息者中各个关键节点的耗时都打印出来了。

发现有两个地方耗时比较长:

  1. 有个代码是一个for循环中,一个个查询数据库处理数据的。
  2. 有个多条件查询数据的代码。

于是,我做了有针对性的优化。

将在for循环中一个个查询数据库的代码,改成通过参数集合,​​批量查询​​数据。

有时候,我们需要从指定的用户集合中,查询出有哪些是在数据库中已经存在的。

实现代码可以这样写:

public List<User> queryUser(List<User> searchList) {if (CollectionUtils.isEmpty(searchList)) {return Collections.emptyList();}List<User> result = Lists.newArrayList();searchList.forEach(user -> result.add(userMapper.getUserById(user.getId())));return result;
}

这里如果有50个用户,则需要循环50次,去查询数据库。我们都知道,每查询一次数据库,就是一次远程调用。

如果查询50次数据库,就有50次远程调用,这是非常耗时的操作。

那么,我们如何优化呢?

具体代码如下:

public List<User> queryUser(List<User> searchList) {if (CollectionUtils.isEmpty(searchList)) {return Collections.emptyList();}List<Long> ids = searchList.stream().map(User::getId).collect(Collectors.toList());return userMapper.getUserByIds(ids);
}

提供一个根据用户id集合批量查询用户的接口,只远程调用一次,就能查询出所有的数据。

多条件查询数据的地方,增加了一个​​联合索引​​,解决了问题。

这样优化之后, mq消费者处理消息的速度提升了很多,消息积压问题被解决了。

2 第二次消息积压

没想到,过了几个月之后,又开始出现消息积压的问题了。

但这次是偶尔会积压,大部分情况不会。

这几天消息的积压时间不长,对用户影响比较小,没有引起商家的投诉。

我查了一下划菜表的数据只有几百万。

但通过一些监控,和DBA每天发的慢查询邮件,自己发现了异常。

我发现有些sql语句,执行的where条件是一模一样的,只有条件后面的参数值不一样,导致该sql语句走的索引不一样。

比如:order_id=123走了索引a,而order_id=124走了索引b。

有张表查询的场景有很多,当时为了满足不同业务场景,加了多个联合索引。

MySQL会根据下面几个因素选择索引:

  1. 通过采样数据来估算需要扫描的行数,如果扫描的行数多那可能io次数会更多,对cpu的消耗也更大。
  2. 是否会使用临时表,如果使用临时表也会影响查询速度;
  3. 是否需要排序,如果需要排序则也会影响查询速度。

综合1、2、3以及其它的一些因素,MySql优化器会选出它自己认为最合适的索引。

MySQL优化器是通过采样来预估要扫描的行数的,所谓​​采样​​就是选择一些数据页来进行统计预估,这个会有一定的误差。

由于​​MVCC​​会有多个版本的数据页,比如删除一些数据,但是这些数据由于还在其它的事务中可能会被看到,索引不是真正的删除,这种情况也会导致统计不准确,从而影响优化器的判断。

上面这两个原因导致MySQL在执行SQL语句时,会​​选错索引​​。

明明使用索引a的时候,执行效率更高,但实际情况却使用了索引b。

为了解决MySQL选错索引的问题,我们使用了关键字​​force index​​,来强制查询sql走索引a。

这样优化之后,这次小范围的消息积压问题被解决了。

3 第三次消息积压

过了半年之后,在某个晚上6点多钟。

有几个商家投诉过来,说划菜系统有延迟,下单之后,几分钟才能看到菜品。

我查看了一下监控,发现kafka消息又出现了积压的情况。

查了一下MySQL的索引,该走的索引都走了,但数据查询还是有些慢。

此时,我再次查了一下划菜表,惊奇的发现,短短半年表中有3千万的数据了。

通常情况下,单表的数据太多,无论是查询,还是写入的性能,都会下降。

这次出现查询慢的原因是数据太多了。

为了解决这个问题,我们必须:

  1. 做分库分表
  2. 将历史数据备份

由于现阶段做分库分表的代价太大了,我们的商户数量还没有走到这一步。

因此,我们当时果断选择了将历史数据做备份的方案。

当时我跟产品和DBA讨论了一下,划菜表只保留最近30天的数据,超过几天的数据写入到​​历史表​​中。

这样优化之后,划菜表30天只会产生几百万的数据,对性能影响不大。

消息积压的问题被解决了。

4 第四次消息积压

通过上面这几次优化之后,很长一段时间,系统都没有出现消息积压的问题。

但在一年之后的某一天下午,又有一些商家投诉过来了。

此时,我查看公司邮箱,发现kafka消息积压的监控报警邮件一大堆。

但由于刚刚一直在开会,没有看到。

这次的时间点就有些特殊。

一般情况下,并发量大的时候,是中午或者晚上的用餐高峰期,而这次出现消息积压问题的时间是​​下午​​。

这就有点奇怪了。

刚开始查询这个问题一点头绪都没有。

我问了一下订单组的同事,下午有没有发版,或者执行什么功能?

因为我们的划菜系统,是他们的下游系统,跟他们有直接的关系。

某位同事说,他们半小时之前,执行了一个批量修改订单状态的job,一次性修改了几万个订单的状态。

而修改了订单状态,会自动发送mq消息。

这样导致,他们的程序在极短的时间内,产生了大量的mq消息。

而我们的mq消费者根本无法处理这些消息,所以才会产生消息积压的问题。

我们当时一起查了kafka消息的积压情况,发现当时积压了几十万条消息。

要想快速提升mq消费者的处理速度,我们当时想到了两个方案:

  1. 增加partion数量。
  2. 使用线程池处理消息。

但考虑到,当时消息已经积压到几个已有的partion中了,再新增partion意义不大。

于是,我们只能改造代码,使用​​线程池处​​理消息了。

为了开始消费积压的消息,我们将线程池的​​核心线程​​和​​最大线程​​数量调大到了50。

这两个参数是可以动态配置的。

这样调整之后,积压了几十万的mq消息,在20分钟左右被消费完了。

这次突然产生的消息积压问题被解决了。

解决完这次的问题之后,我们还是保留的线程池消费消息的逻辑,将核心线程数调到​​8​​,最大线程数调到​​10​​。

当后面出现消息积压问题,可以及时通过调整线程数量,先临时解决问题,而不会对用户造成太大的影响。

注意:使用线程池消费mq消息不是万能的。该方案也有一些弊端,它有消息顺序的问题,也可能会导致服务器的CPU使用率飙升。此外,如果在多线程中调用了第三方接口,可能会导致该第三方接口的压力太大,而直接挂掉。

总之,MQ的消息积压问题,不是一个简单的问题。

虽说产生的根本原因是:MQ生产者生产消息的速度,大于MQ消费者消费消息的速度,但产生的具体原因有多种。

我们在实际工作中,需要针对不同的业务场景,做不同的优化。

我们需要对MQ队列中的消息积压情况,进行监控和预警,至少能够及时发现问题。

没有最好的方案,只有最合适当前业务场景的方案。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/pingmian/11974.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

外卖订餐总后台系统原型

页面数量&#xff1a;共 210 页 源文件格式&#xff1a;rp格式&#xff0c;兼容 Axure RP 9/10 应用领域&#xff1a;O2O领域、网上订餐、外卖行业 文章展示不够全面&#xff0c;如有兴趣请联系作者 该原型作品为外卖订餐总后台管理系统&#xff0c;定位偏向美团外卖与饿了么一…

研发管理之认识DevOps

文章目录 一、什么是DevOps二、DevOps的背景和起源三、DevOps的特点和价值1、特点&#xff1a;2、价值&#xff1a; 四、DevOps如何帮助提高软件交付速度和质量 一、什么是DevOps DevOps&#xff08;Development和Operations的组合词&#xff09;是一组过程、方法与系统的统称…

MySQL的msi格式安装

一、下载链接 MySQL :: Download MySQL Installer (Archived Versions) 二、安装步骤 ①选择自定义安装 ②选择要安装的产品 ③安装依赖环境 ④安装 ⑤点击下一步 ⑥配置 ⑦设置密码 ⑧命名 ⑨数据存放路径 ⑩安装配置 ①①配置环境变量 ①②验证 方法一&#xff1a; 方法二…

批量文件夹随机重命名:一键操作,提升管理效率的技巧

在数字化时代&#xff0c;文件夹的管理是日常工作中不可或缺的一部分。对于拥有大量文件夹的用户来说&#xff0c;批量文件夹重命名是提高工作效率的关键步骤。而随机重命名不仅能增加文件组织的多样性&#xff0c;还能在一定程度上保护隐私。本文将介绍云炫文件管理器如何通过…

GPT4o速测:约0.5秒延迟的多模态能力

文章目录 1. 测评2. IntroReference 没有剪辑&#xff0c;约0.5秒延迟的多模态能力。 1. 测评 推理速度异常快&#xff0c;比之前快了大概两三倍&#xff0c;对产品端来说是个很好的事情&#xff0c;想用gpt4级别性能终于可以少讨论几句时延影响用户体验了模型指令遵从能力变强…

邦芒职场:战胜职业倦怠,焕发职场新活力

职业倦怠&#xff0c;这一现代职场的隐形杀手&#xff0c;正悄然侵蚀着无数职场人的身心。随着工作量的持续增长和数字化设备的普及&#xff0c;我们被无数的信息和任务所包围&#xff0c;仿佛永远都有做不完的工作。长期下来&#xff0c;这种压力累积导致我们感到疲惫、紧张&a…

【2024】前端,该卷什么呢?

✅顺便推个机会&#xff0c;技术大厂&#xff0c;部门捞人&#xff0c;前后端可投。 2024ChatGPT 的炸裂式发展&#xff0c;很多大佬都亲自入场整活儿&#xff0c;你不得不说&#xff0c;人工智能时代的未来已来&#xff0c;大势所趋&#xff0c;不可阻挡。随着生成式AI的迅猛发…

电脑没有网络连接怎么办?4招轻松完成网络连接!

“我的电脑开机后发现连接不上网络&#xff0c;尝试了很多次也不行&#xff0c;这是因为什么呢&#xff1f;有什么比较好的解决方法吗&#xff1f;” 当电脑无法连接到网络时&#xff0c;可能会给我们的工作和生活带来诸多不便。然而&#xff0c;大多数网络连接问题都可以通过一…

申请免费的域名证书

免费域名证书主要是由一些证书颁发机构&#xff08;CA&#xff09;提供的&#xff0c;用于为网站启用HTTPS加密的数字证书&#xff0c;目的是保障网站数据传输的安全性。这些证书的特点和获取途径如下&#xff1a; 功能与目的&#xff1a;免费域名证书能够帮助网站实现基本的加…

springboot+vue+mybatis生活废品回收系统+PPT+论文+讲解+售后

该生活废品回收系统采用B/S架构、前后端分离以及MVC模型进行设计&#xff0c;并采用java语言以及springboot框架进行开发。该系统主要设计并完成了管理过程中的用户登录、个人信息修改、义捐活动、在线咨询、订单评价、废品订单、废品、回收再利用技巧、废品回收员、用户等功能…

机器学习——4.案例: 简单线性回归求解

案例目的 寻找一个良好的函数表达式,该函数表达式能够很好的描述上面数据点的分布&#xff0c;即对上面数据点进行拟合。 求解逻辑步骤 使用Sklearn生成数据集定义线性模型定义损失函数定义优化器定义模型训练方法&#xff08;正向传播、计算损失、反向传播、梯度清空&#…

react+antd --- 日期选择器,动态生成日期表格表头

先看一下效果---有当前月的日期 技术&#xff1a; 1&#xff1a; react 2&#xff1a;antd-UI库 -- table 3&#xff1a;moment--时间处理库 代码效果&#xff1a; import { Button, DatePicker, Table } from antd; import { useEffect, useState } from react; import momen…

信号和槽的使用

&#x1f40c;博主主页&#xff1a;&#x1f40c;​倔强的大蜗牛&#x1f40c;​ &#x1f4da;专栏分类&#xff1a;QT❤️感谢大家点赞&#x1f44d;收藏⭐评论✍️ 目录 一、连接信号和槽 二、查看内置信号和槽 三、通过 Qt Creator 生成信号槽代码 一、连接信号和槽 …

快捷自由定时重启、注销、关机

首先&#xff0c;需要用到的这个工具&#xff1a; 度娘网盘 提取码&#xff1a;qwu2 蓝奏云 提取码&#xff1a;2r1z 1、打开工具&#xff0c;进入定时器编辑版块 2、左侧目录新建一个定时器 3、选择需要的周期&#xff0c;这里是每天0点&#xff0c;一次执行一条 4、添加具…

牛客热题:二叉树的中序遍历

&#x1f4df;作者主页&#xff1a;慢热的陕西人 &#x1f334;专栏链接&#xff1a;力扣刷题日记 &#x1f4e3;欢迎各位大佬&#x1f44d;点赞&#x1f525;关注&#x1f693;收藏&#xff0c;&#x1f349;留言 文章目录 牛客热题&#xff1a;二叉树的中序遍历题目链接方法一…

python对排列三的分析

对排列三(一种常见的彩票游戏)进行分析,我们通常关注其号码组合的可能性、中奖概率以及可能的号码趋势或模式。然而,由于排列三是基于随机抽取的,因此没有一种方法可以预测下一个中奖号码,但我们可以通过Python来分析历史数据和统计信息。 以下是一个简单的Python脚本示…

js发票查验、票据OCR接口助力解决发票录入与真假辨别难题

作为消费者&#xff0c;每位都是税法的监督员&#xff0c;为了保护自己的合法权益、共同维护市场秩序&#xff0c;消费者进行实际交易后无论是否需要报销&#xff0c;都应该主动向商家索取发票。一般来说发票主要有三种&#xff1a;增值税专用发票、普通发票、专业发票。以下&a…

openGauss安装完成后,切换用户提示ulimit open files cannot modify limit

openGauss安装完成后&#xff0c;切换用户提示ulimit open files cannot modify limit su - omm Last login: Wed Apr 17 14:13:01 CST 2024 on pts/0 -bash: ulimit: open files: cannot modify limit: Operation not permitted通过研究发现&#xff0c;是在安装openGauss的时…

【算法基础实验】排序-最小优先队列MinPQ

优先队列 理论知识 MinPQ&#xff08;最小优先队列&#xff09;是一种常见的数据结构&#xff0c;用于有效管理一组元素&#xff0c;其中最小元素可以快速被检索和删除。这种数据结构广泛应用于各种算法中&#xff0c;包括图算法&#xff08;如 Dijkstra 的最短路径算法和 Pr…

python中的矩阵操作

1 矩阵的每行加上同一行 print(np.array([[0,0,1],[1,1,1],[2,2,1]])[1,1,1])2 两个矩阵AB(相同列数不同行)拼接&#xff0c;B按行拼接在A后面 np.row_stack((A,B)))3 一个矩阵的每个元素都加上同一个常数 print(np.array([[0,0,1],[1,1,1],[2,2,1]])1)矩阵中每个数都会加1 …