记一次线上问题 → Deadlock 的分析与优化

这篇具有很好参考价值的文章主要介绍了记一次线上问题 → Deadlock 的分析与优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

开心一刻

  今天女朋友很生气

  女朋友:我发现你们男的,都挺单纯的

  我:这话怎么说

  女朋友:脑袋里就只想三件事,搞钱,跟谁喝点,还有这娘们真好看

  我:你错了,其实我们男人吧,每天只合计一件事

  女朋友:啥事呀?

  我:这娘们真好看,得搞钱跟她喝点

记一次线上问题 → Deadlock 的分析与优化

问题复现

  需求背景

   MySQL8.0.30 ,隔离级别是默认的,也就是 REPEATABLE-READ 

  表: tbl_class_student ,id 非自增,整张表的全部字段数据都是从上游服务进行同步

记一次线上问题 → Deadlock 的分析与优化

  需求:上游服务发送同步MQ,本服务收到消息后再调上游服务接口,查询全量数据,对 tbl_class_student 表数据进行更新,若记录存在则更新,不存在则插入

  这需求是不是很明确?放心,没有下套!

记一次线上问题 → Deadlock 的分析与优化

  线上问题

  通过线上异常日志,最终定位到如下代码

记一次线上问题 → Deadlock 的分析与优化

  咋一看,这代码是不是无比的清晰明了?

  都不用注释,就能清楚的知道这个代码是在做什么:逐行更新,存在则更新,不存在则插入

  是不是无比的契合需求?

记一次线上问题 → Deadlock 的分析与优化

  但是,真的就完美无瑕吗

  且看我表演一波

记一次线上问题 → Deadlock 的分析与优化

  表演代码如下:

记一次线上问题 → Deadlock 的分析与优化记一次线上问题 → Deadlock 的分析与优化
@Override
@Transactional(rollbackFor = Exception.class)
public void batchSaveOrUpdate(List<TblClassStudent> classStudents) {
    if(CollectionUtils.isEmpty(classStudents)) {
        return;
    }
    classStudents.forEach(classStudent -> {
        this.getBaseMapper().saveOrUpdate(classStudent);
        try {
            // 为了方便复现问题,睡眠1秒
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
}

// 单元测试
@Test
public void batchSaveOrUpdateTest() throws InterruptedException {

    TblClassStudent classStudent = new TblClassStudent();
    classStudent.setId(1);
    classStudent.setClassNo("20231010");
    classStudent.setStudentNo("20231010201");

    TblClassStudent classStudent1 = new TblClassStudent();
    classStudent1.setId(2);
    classStudent1.setClassNo("20231010");
    classStudent1.setStudentNo("20231010202");

    List<TblClassStudent> classStudents1 = new ArrayList<>();
    classStudents1.add(classStudent);
    classStudents1.add(classStudent1);

    List<TblClassStudent> classStudents2 = new ArrayList<>();
    classStudents2.add(classStudent1);
    classStudents2.add(classStudent);

    // 模拟2个线程,同时批量更新
    CountDownLatch latch = new CountDownLatch(2);
    new Thread(() -> {
        studentService.batchSaveOrUpdate(classStudents1);
        latch.countDown();
    }, "t1").start();
    new Thread(() -> {
        studentService.batchSaveOrUpdate(classStudents2);
        latch.countDown();
    }, "t2").start();
    latch.await();
    System.out.println("主线程执行完毕");
}
View Code

   Deadlock 就这么诞生了!

记一次线上问题 → Deadlock 的分析与优化

优化处理

  死锁产生条件

  死锁产生的条件,大家还记得吗?

记一次线上问题 → Deadlock 的分析与优化

  回到上诉案例,锁的持有、申请情况如下

记一次线上问题 → Deadlock 的分析与优化

  死锁自然就产生了

  那么该如何处理了

  排序处理

  不同线程调用同一个方法处理数据而产生死锁

  这种情况对处理的数据进行排序处理,使得不同线程申请数据库锁的顺序保持一致,那么就不会产生死锁

记一次线上问题 → Deadlock 的分析与优化

  分批处理

  事务时间越短越好

  批量逐条更新,会导致事务持续的时间很长,那么出现死锁的概率就越大

  分批处理可以减少事务时长

记一次线上问题 → Deadlock 的分析与优化

  加锁处理

  这里的锁指的并非数据库层面的锁,而是业务代码层面的锁

  可以是 JVM 的锁,适用于单节点部署的情况

  可以是分布式锁,适用于单节点部署,也适用于多节点部署;具体实现方式有很多,结合实际情况选择一种合适的实现方式即可

总结

  1、批量逐条更新,这是严令禁止的

    效率低下,导致事务时长大大增加,会引发一系列其他的问题

  2、数据库的加锁是比较复杂的,不同的数据库的加锁实现也是有区别的

    本篇中的死锁案例还是比较好分析的

    遇到不好分析的,需要向同事(dba、开发同事等)发出求助,也可以线上求助数据库博主

  3、面对不同问题,结合业务来分析出最合适的处理方式

    有的业务对性能要求高

    有的业务对数据准确性要求高

    文章来源地址https://www.toymoban.com/news/detail-617220.html

到了这里,关于记一次线上问题 → Deadlock 的分析与优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次线上BUG排查过程

    1. 线上遇到一个非常奇怪的bug,为一个用户分配业务线类型后,该用户登录时,提示502,但其它的用户登录完全是正常的 2. 问题现象 3. 排查思路 先去看线上日志,看是否有error,但日志里边这个接口200正常返回 本地debug,也复现一样问题,在分配角色类型超过22个总数时就报

    2024年02月09日
    浏览(50)
  • 记一次线上kafka造成的事故

    背景:所有的原始数据均存储在mysql,mysql会通过binlog将数据同步至kafka消息队列,但是有人将mysql中的数据进行删除(大概有2、3年的数据),被删除的数据也通过binlog被同步至消息队列里导致大量消息积压,且该消息队列只有3个分区,最多3个线程消费,消费方即使过滤也远

    2024年02月13日
    浏览(42)
  • 得物-Golang-记一次线上服务的内存泄露排查

    在风和日丽的一天,本人正看着需求、敲着代码,展望美好的未来。突然收到一条内存使用率过高的告警。 告警的这个项目,老代码是python的,最近一直在go化。随着go化率不断上升,发现内存的RSS使用率越飙越高。最终达到容器内存限制后,进程会自动重启。RSS如下图所示

    2024年02月04日
    浏览(58)
  • 记一次线上mysql出错:由于docker自动拉取最新mysql镜像导致mysql容器无法启动

    我随便写写,你们随便看看 环境背景:在docker中部署mysql镜像,通过portainer管理docker容器 简单说下过程:docker里mysql的时区没有设置,导致相差8小时,通过增加TZ=Asiz/Shanghai环境变量,然后重启容器来生效。结果重启的时候始终无法启动起来,后来发现是自动升级了mysql镜像版

    2024年02月07日
    浏览(51)
  • 记一次线上bug排查-----SpringCloud Gateway组件 请求头accept-encoding导致响应结果乱码

           基于公司的业务需求,在SpringCloud Gateway组件的基础上,写了一个转发服务,测试开发阶段运行正常,并实现初步使用。但三个月后,PostMan请求接口,返回异常,经排查,从日志中获取到转发响应的结果为乱码:        跟踪日志: 转发到目标接口,响应结果已乱码

    2024年02月04日
    浏览(49)
  • 一次线上mysql 调优 ,join 的调优,索引优化(Block Nested Loop)

    原因: 某接口调用十分缓慢,通过 Explain 发现是SQL问题 可以看到,在Join连接时,出现了BNL查询,BNL出现是因为,JOIN连接时 dr表也就是 domian_redemption 被驱动的表上没出现可用的索引。 个人解决方法: 在对应的连接字段上,既dr的orderCode字段,内表加上索引,再次执行Explai

    2024年02月05日
    浏览(46)
  • 通过一次线上问题,讲下Ribbon重试机制

    前段时间,产品经理在线上验证产品功能的时候,发现某个功能不符合需求预期,后来测试验证发现是服务端的一个接口大概率偶现超时,前端做了兜底处理,所以对线上用户么有太大影响。 由于服务端的接口偶现超时,并且网关设置了30s超时熔断,所以前端请求就直接报错

    2024年02月15日
    浏览(57)
  • 记一次 Redisson 线上问题 → ERR unknown command 'WAIT' 的排查与分析

    昨晚和一个朋友聊天 我:处对象吗,咱俩试试? 朋友:我有对象 我:我不信,有对象不公开? 朋友:不好公开,我当的小三 程序在生产环境稳定的跑着 直到有一天,公司执行组件漏洞扫描,有漏洞的  jar  要进行升级修复 然后我就按着扫描报告将有漏洞的  jar  修复到指

    2024年02月09日
    浏览(53)
  • 记一次应用程序池崩溃问题分析

    IIS部署的asp.net core服务,前端进行一些操作后,经常需要重新登陆系统。 根据日志,可以看到服务重新进行了初始化,服务重启应该与IIS应用程序池回收有关,查看IIS相关日志,在windows的事件查看器=Windows日志=系统,来源为WAS的日志(参考博客)。 根据IIS日志与服务日志对比

    2024年02月04日
    浏览(46)
  • 记一次使用NetworkManager管理Ubuntu网络无效问题分析

    我们都知道CentOS、Redhat系列网络配置比较连贯,要么在 /etc/sysconfig/network-scripts/ifcfg-网络设备名 ,文件中编辑后,重启网络服务;要么使用 nmtui 或者 nmcli 进行配置。但是, Ubuntu变动就比较大: 早期 版本的Ubuntu,配置网络在 /etc/network/interfaces 下,后面这个文件就被遗弃了,

    2024年02月09日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包