数据库死锁导致分布事务中大批量更新数据库不成功

1 问题描述

未签收的订单十五天之后自动签收:总共2个步骤: step1 在乐购系统中批量更新未签收订单的状态,step2: 通过RPC修改订单系统的订单状态, step1和step2放到一个事务中。然后发现step2 订单DB状态修改成功,但是step1 乐购db的订单状态并未修改。

2 排查过程

1. 怀疑是程序的问题,检查乐购系统的执行日志,发现所有日志执行成功,db的插入和更新操作日志以及事务日志,都显示执行正确;【正常】

2. 怀疑是DB执行的问题,检查DB的binglog日志,发现没有事务执行的任何记录,那数据到底是提交到哪里去了呢? 乐购系统的日志明明是显示执行成功的啊。于是怀疑当时db执行可能有错误再检查db的errorlog发现也没有任何db执行错误信息;【正常】

3. 怀疑是db的配置问题,因为我们当时在dev和qa环境下都测试成功,就是boss环境发生这样的奇怪问题。于是检查dev,qa和boss环境的所有配置,包括:bulk_insert_buffer_size 批量插入buffer大小,innodb_flush_log_at_trx_commit 事务提交的日志级别,lock timewait锁等待时间,注意这个参数很重要。默认是5分钟吧,我们设置的是365天!!【不正常】

4. 发现这三个环境没有db配置没有任何差别,唯一不同的是线上db做了主从配置。难道主从配置会影响到事务提交的级别,这个也有可能,因为db主从同步会写binglog日志,而binglog又是事务执行必须日志(还有redolog),于是google db主从同步对事务的影响,没发现任何信息;【正常】

这时再重现梳理思路,那就是剩下2种可能:

1. 乐购系统的数据根本就没有提交到db,由于网络问题什么的,如果这种问题的话,spring+mybatis会有错误日志,db超超时问题的(当时准备不行再用tcpdump验证下3306端口,但是这个问题只能在boss环境出现,没办法tcpdump);【正常】

2. 数据已经到达db了,由于db自身的问题或约束而没有执行。对,是不是db有啥约束,google之后发现确实有一个参数:max_allowed_packet 这个参数对事务批量提交时数据大小有限制,我们设置的是16m, 难道我们boss环境下事务一次提交的数据超过这个了,检查了提交记录数据,打开128k 字节,远远小于16m。排除这个参数。【正常】

查看INNODB状态日志:【不正常,DB死锁】

3 解决问题

修改db中的 lock timewait锁等待时间,线上数据即使死锁也可以快速释放锁;

修改程序,把step2 rpc调用修改为异步执行,注意这样修改导致事务实际上无效了;

4 总结问题

这里我们也检查了我们的程序确实也有问题,一个事务包括在step1和step2中,而step2采用rpc调用时间特别长(>2分钟),这样导致step1中事务无法及时提交,这个过程中db一直等待commit,而线上数据肯定也会实时更新db,很容易发生死锁。

架构师视频资料分享链接:

data:text/html;charset=UTF-8;base64,

5p625p6E5biI5a2m5Lmg5Lqk5rWB576k5Y+35pivNTc1NzUxODU0Cg==

复制粘贴在网站即可!

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180130A0NS9M00?refer=cp_1026

同媒体快讯

相关快讯

扫码关注云+社区