记一次线上问题引发的对 Mysql 锁机制分析

背景

最近双十一开门红期间组内出现了一次因 Mysql 死锁导致的线上问题,当时从监控可以看到数据库活跃连接数飙升,导致应用层数据库连接池被打满,后续所有请求都因获取不到连接而失败

整体业务代码精简逻辑如下:

@Transaction
public void service(Integer id) {delete(id);insert(id);
}

数据库实例监控:







当时通过分析上游问题流量限流解决后,后续找时间又重新分析了下问题发生的根本原因,现将其总结如下:本篇文章会先对 Mysql 中的各种锁进行分析,包括互斥锁、间隙锁和插入意向锁,让大家对各种锁的使用场景有一个了解,然后在此基础上再对本问题进行分析,希望大家未来再碰到相似场景时,能够快速的定位问题

Mysql 锁机制

在 Mysql 中为了解决对同一行记录并发写的问题,引入了行锁机制,多个事务不能同时对一行数据进行修改操作,当需要对数据库中的一行数据进行修改时,会首先判断该行数据是否加锁,如果没加锁,那么当前事务加锁成功,可以进行后续的修改操作;但如果该行数据已经被其他事务加锁,则当前事务只有等待加锁的事务释放锁后才能加锁成功,继续执行修改操作

本篇文章中所有实验用到的建表语句:

create table `test` (`id` int(11) NOT NULL,`num` int(11) NOT NULL,PRIMARY KEY (`id`),KEY `num` (`num`)
) ENGINE = InnoDB;insert intotest
values
(10, 10),
(20, 20),
(30, 30),
(40, 40),
(50, 50);

Shared and Exclusive Locks

shared(S) lock 表示共享锁,当一个事务持有某行上的 S 锁后可以对该行的数据进行读操作,通过语句 select ... from test lock in share mode 可以添加共享锁,一般使用的较少,不做过多阐述

exclusive(X) lock 表示互斥锁,当一个事务对某行数据进行 update 或 delete 操作时都要先获取到该记录上的 X 锁,如果已经有其他事务获取到了该记录上的 X 锁,那么当前事务会阻塞等待直到上一事务释放了对应记录上的 X 锁

S 锁之间不互斥,多个事务可以同时获取一条记录上的 S 锁 X 锁之间互斥,多个事务不能同时获取同一条记录上的 X 锁 S 锁和 X 锁之间互斥,多个事务不能同时获取同一条记录上的 S 锁和 X 锁

当多个事务同时去 update 索引上同一条记录时,都需要先获取到该记录上的 X 锁,所谓的锁也就是会在内存中生成一个数据结构来记录当前的事务信息、锁类型和是否等待等信息。下图中就是 T1 和 T2 同时去更新 id = 30 的这行记录,并且 T1 成功获取到了锁,其在内存中生成的锁结构信息中字段 is_wating 为 false,可以继续执行事务的后续逻辑,而 T2 获取锁失败,则生成的锁结构信息字段 is_wating 为 true,阻塞等待 T1 上的锁释放





互斥锁在 Mysql 日志中的锁信息为:lock_mode X locks rec but not gap

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10078 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 00: len 4; hex 8000000a; asc     ;;1: len 6; hex 00000000274f; asc     'O;;2: len 7; hex b60000019d0110; asc        ;;

Gap Locks

上一小节中介绍了 Exclusive Locks,该锁可以避免多个事务同时对一行记录进行更新操作,但不能解决幻读的问题,所谓的幻读就是指一个事务在前后两次查询同一个范围时,后一次查询到了前一次没有的记录

session Asession B
T1select num from test where num > 10 and num < 15 for update; (0 rows)
T2insert into test values(12, 12);
T3select num from test where num > 10 and num < 15 for update; (1 rows)

在上面这个场景中,session A 分别在 T1、T3 时刻进行了两次范围查询,session B 在 T2 时刻插入了一条该范围内的数据,如果 session A 能在 T3 时刻查询出 session B 插入的数据,就说明发生了幻读。此时只使用互斥锁是无法解决幻读的,因为 num = 12 的记录在数据库中还不存在,不能给其加上互斥锁来防止 T2 时刻 session B 的插入

因此为了解决幻读问题,只有引入新的锁机制,也就是间隙锁(Gap Locks)。间隙锁和互斥锁不同,互斥锁是行锁,只会锁定一行特定的记录,而间隙锁则是锁定两行记录之间的空隙,防止其他事务在此间隙中插入新的记录

引入了间隙锁之后,session A 在 T1 时刻会给 id = 20 记录生成一个 Gap Locks,之后 session B 在 T2 时刻想要插入记录时,需要先判断待插入位置的后一条记录上是否存在 Gap Locks,很明显此时 id = 20 的记录上已经存在了 Gap Locks,那么session B 就需要在 id = 20 的记录上生成一个插入意向锁,并进入锁等待





间隙锁在 Mysql 中的锁日志信息如下:lock_mode X locks gap before rec

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38849 lock_mode X locks gap before rec
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 00: len 4; hex 8000001e; asc     30 ;;1: len 6; hex 00000000969c; asc       ;;2: len 7; hex a60000011a0128; asc       (;;3: len 4; hex 8000001e; asc     ;;

间隙锁虽然解决了幻读问题,但因每次都会锁住一段间隙,大大降低了数据库整体的并发度,且因间隙锁和间隙锁之间不互斥,不同事务可以同时对同一间隙加上 Gap Locks,这也往往是各种死锁产生的源头

Next-Key Locks

Next-Key Locks 是 (Shard/Exclusive Locks + Gap Locks) 的结合,当 session A 给某行记录 R 添加了互斥型的 Next-Key Locks 后, 相当于拥有了记录 R 的 X 锁和记录 R 的 Gap Locks

在上面 Gap Locks 的例子中事务 1 加的就是 Next-Key Locks,即同时给 id = 20 的记录加了 X 锁和 Gap 锁





在可重复读隔离级别下,update 和 delete 操作默认都会给记录添加 Next-Key Locks,Mysql 中 Next-Key Locks 的锁日志信息为:lock_mode X

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10080 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 00: len 8; hex 73757072656d756d; asc supremum;;Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 00: len 4; hex 8000000a; asc     ;;1: len 6; hex 00000000274f; asc     'O;;2: len 7; hex b60000019d0110; asc        ;

Insert Intention Locks

插入意向锁(Insert Intention Locks) 也是一种间隙锁,由 INSERT 操作在行数据插入之前获取

在插入一条记录前,需要先定位到该记录在 B+ 树中的存储位置,然后判断待插入位置的下一条记录上是否添加了 Gap Locks,如果下一条记录上存在 Gap Locks,那么插入操作就需要阻塞等待,直到拥有 Gap Locks 的那个事务提交,同时执行插入操作等待的事务也会在内存中生成一个锁结构,表明有事务想在某个间隙中插入新记录,但目前处于阻塞状态,生成的锁结构就是插入意向锁

实验模拟如下:

session 1session 2session 3
T1begin;
T2select * from test where id = 25 for update;
T3insert into test values(26, 26); (blocked)
T4insert into test values(26, 26); (blocked)

对于语句 select * from test where id = 25 for update 因当前表中不存在该记录,在可重复读隔离级别下,为了避免幻读,会给 (20, 30] 间隙加上 Gap Locks

从锁日志可以看出 session 1 给记录 30 添加了间隙锁(lock_mode X locks gap before rec)

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38849 lock_mode X locks gap before rec
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 00: len 4; hex 8000001e; asc     30 ;;1: len 6; hex 00000000969c; asc       ;;2: len 7; hex a60000011a0128; asc       (;;3: len 4; hex 8000001e; asc     ;;

当 session 2 插入记录 26 时,会在 B+ 树中先定位到待插入位置,再判断插入位置的间隙是否存在 Gap Locks,也就是判断待插入位置的后一记录 id = 30 是否存在 Gap Locks,如果存在需要在该记录上生成插入意向锁等待

RECORD LOCKS space id 133 page no 3 n bits 80 index PRIMARY of table `test`.`test` trx id 38850 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 00: len 4; hex 8000001e; asc    30 ;;1: len 6; hex 00000000969c; asc       ;;2: len 7; hex a60000011a0128; asc       (;;3: len 4; hex 8000001e; asc     ;;

此时 session 2 和 session 3 都在 id = 30 的记录上添加了插入意向锁等待 session 1 上的 Gap Locks 释放,生成的锁记录如下:







线上问题分析

在对 Mysql 中的各种锁结构有了一个清晰的了解之后,回过头来再看看前面的线上问题

@Transaction
public void service(Integer id) {delete(id);insert(id);
}

对于上面的业务代码可能存在下面两种情况:

•传入的参数 id 在原数据库中不存在

•传入的参数 id 在原数据库中存在

本次主要会针对 id 记录在原数据库中不存在进行分析

session 1session 2session 3
T1delete from test where id = 15;
T2delete from test where id = 15;delete from test where id = 15;
T3insert into test values(15, 15);
T4insert into test values(15, 15);
T5insert into test values(15, 15);

因 id = 15 在数据库中不存在,在 T1 时刻 session 1 会给其所在间隙的下一条记录添加上 Gap Locks,又因 Gap Locks 不互斥, 在 T2 时刻 session 2 和session 3 都会同时获取到 id = 20 的 Gap 锁

下图中 tx: T1、T2、T3 分别代表 session 1、session 2 和 session 3





当在 T3 时刻 session 1 插入 id = 15 的记录时,会判断其插入位置的后一条记录是否存在 Gap Locks,如果存在,则需要在该记录上生成 Insert Intention Locks 并等待持有 Gap Locks 的事务释放锁





在 T4 时刻 session 2 执行插入语句,同样会因插入位置的后一条记录中存在 Gap Locks 而需要生成 Insert Intention Locks 等待。此时很明显就形成了死锁,session 1 生成插入意向锁等待 session 2 和 session 3 上的 Gap 锁释放,而 session 2 同样生成插入意向锁等待 session 1 和 session 3 上的 Gap 锁释放





在 T4 时刻检测到死锁后,Mysql 会选择其中一个事务进行回滚,假设此时 session 2 被回滚,释放了其持有的所有锁资源,session 1 可以继续执行吗? 很明显不可以,session 1 还同时在等待 session 3 上的 Gap 锁释放,继续阻塞等待

在 T5 时刻 session 3 开始执行插入语句,此时同 T4 时刻,死锁形成,session 1 生成的插入意向锁正在等待 session 3 上的 Gap Locks 释放,session 3 上生成的插入意向锁正在等待 session 1 上的 Gap Locks 释放,此时 session 3 回滚释放所有锁资源后,session 1 才可以最终执行成功





在完成了三个并发线程的死锁分析后,可能有人会想虽然有死锁,但通过死锁检测可以很快的检测出,程序也可以正常的执行,这有什么问题呢? 其实上面没有问题主要是因为并发量较小,死锁检测可以很快检测出,如果此时将并发量扩大 100 倍甚至 1000 倍后,还会没有问题吗?

看看当时出现线上问题时,接口的调用量情况,





进一步在本地模拟 300 个线程并发执行,因人脑并发分析所有事务的执行情况的话会非常复杂,本次只以事务 1 为一个点来进行分析

从图中可以看到当 T1 在执行插入语句时,需要等待 T2- T101 上持有的 Gap Locks 释放,之后 T2 - T6 可能同时执行插入语句,然后进行死锁检测,事务回滚,看着似乎只要后续有事务执行了插入语句就会执行死锁回滚,正常运行,但在死锁检测的过程中还会有新事务(T101 - T 200 )获取到 Gap Locks,造成锁等待队列中的事务越来越多,而 Mysql 的整体死锁检测时间复杂度为 O(n^2),锁等待队列中的事务较多时,每一次有新事务进行锁等待,死锁检测都需要遍历锁等待队列中在其之前等待的事务,判断是否会因自己的加入形成环,此时检测会非常消耗 CPU 资源,造成数据库整体性能下降,死锁检测耗时增加,Mysql 活跃连接数大幅增加,并且因锁等待而连接无法释放,最终造成应用层连接池被打满





综上分析,本次出现问题的最主要原因是在短时间内存在大并发的请求对同一行数据进行先删除再插入操作(先更新再插入同理),造成了死锁等待,应用层连接池被打满,大量上游请求超时重试,进一步导致锁等待,最终影响了所有依赖该数据库的业务

因此对于未来在业务代码中存在相似逻辑的地方,一定要做好防重校验,避免短时间内存在对同一行数据的先更新再插入的并发操作。同时在可重复读隔离别下,更新和删除操作默认都会添加 Next-Key Locks,间隙锁的引入使得死锁问题在并发情况下很容易出现,这也是在业务逻辑实现上需要考虑的问题。

总结

本文以一个线上问题为背景,对 Mysql 中的各种锁机制进行了详细的总结,分析了各个锁的加锁时机和具体使用场景,其中特别要注意间隙锁的使用,因间隙锁和间隙锁之间不互斥,当多个事务之间并发执行时很容易形成死锁

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

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

相关文章

机器学习线性代数知识补充

线性代数知识补充 正交矩阵与正交变换方阵特征值与特征向量相似矩阵对角化二次型正定二次型 正交矩阵与正交变换 方阵特征值与特征向量 相似矩阵 对角化 二次型 正定二次型

【C++】类与对象 I

类与对象 I &#xff1a; 前言&#xff1a;&#xff08;C&#xff09;面向过程 和&#xff08;C&#xff09;面向对象 初步认识前言&#xff1a;类的引入一、类的介绍二、类的定义&#xff08;一&#xff09;class 语法&#xff08;二&#xff09;类的两种定义方式&#xff1a;…

YOLO目标检测——番茄数据集下载分享【含对应voc、coco和yolo三种格式标签】

实际项目应用&#xff1a;番茄检测数据集说明&#xff1a;番茄目标检测数据集&#xff0c;真实场景的高质量图片数据&#xff0c;数据场景丰富标签说明&#xff1a;使用lableimg标注软件标注&#xff0c;标注框质量高&#xff0c;含voc(xml)、coco(json)和yolo(txt)三种格式标签…

Interactive Analysis of CNN Robustness

Interactive Analysis of CNN Robustness----《CNN鲁棒性的交互分析》 摘要 虽然卷积神经网络&#xff08;CNN&#xff09;作为图像相关任务的最先进模型被广泛采用&#xff0c;但它们的预测往往对小的输入扰动高度敏感&#xff0c;而人类视觉对此具有鲁棒性。本文介绍了 Pert…

数据结构上机实验——图的实现(以无向邻接表为例)、图的深度优先搜索(DFS)、图的广度优先搜索(BFS)

文章目录 数据结构上机实验1.要求2.图的实现&#xff08;以无向邻接表为例&#xff09;2.1创建图2.1.1定义图的顶点、边及类定义2.1.2创建无向图和查找2.1.3插入边2.1.4打印函数 2.2图的深度优先搜索&#xff08;DFS&#xff09;2.3图的广度优先搜索&#xff08;BFS&#xff09…

代码随想录算法训练营第五十天|123. 买卖股票的最佳时机 III、188. 买卖股票的最佳时机 IV

第九章 动态规划part11 123. 买卖股票的最佳时机 III 给定一个数组&#xff0c;它的第 i 个元素是一支给定的股票在第 i 天的价格。 设计一个算法来计算你所能获取的最大利润。你最多可以完成 两笔 交易。 注意&#xff1a;你不能同时参与多笔交易&#xff08;你必须在再次…

BES2700H开发不完全手册

BES2700H开发不完全手册 是否需要申请加入数字音频系统研究开发交流答疑群(课题组)&#xff1f;可加我微信hezkz17, 本群提供音频技术答疑服务&#xff0c;群赠送语音信号处理降噪算法&#xff0c;ANC AEC ENC EQ BF BES蓝牙耳机音频资料 1 成功编译 2 代码 3 开放文档

高通发布骁龙X Elite Oryon CPU /GitHub出现一款开源项目,让用户“拥有”更大的GPU内存|魔法半周报

我有魔法✨为你劈开信息大海❗ 高效获取AIGC的热门事件&#x1f525;&#xff0c;更新AIGC的最新动态&#xff0c;生成相应的魔法简报&#xff0c;节省阅读时间&#x1f47b; &#x1f525;资讯预览 高通发布骁龙X Elite Oryon CPU&#xff0c;性能超越苹果和英特尔&#xff0…

动手学深度学习——序列模型

序列模型 1. 统计工具1.1 自回归模型1.2 马尔可夫模型 2. 训练3. 预测4. 小结 序列模型是一类机器学习模型&#xff0c;用于处理具有时序关系的数据。这些模型被广泛应用于自然语言处理、音频处理、时间序列分析等领域。 以下是几种常见的序列模型&#xff1a; 隐马尔可夫模型…

ubuntu18.04配置Java环境与安装RCS库

一、安装包 安装包 二、JAVA环境 java无需安装&#xff0c;只需要下载解压&#xff0c;然后配置正确的路径到环境变量种即可使用。 1.创建文件JAVA mkdir JAVA 2.将安装包复制到该文件夹下&#xff0c;并解压缩 tar -zxvf tar -zxvf jdk1.8.0_191.tar.gz 3.在home路径下…

Nexus的Maven私有仓库搭建

Nexus的maven私有仓库搭建 一、了解 maven仓库设置 默认设置 其中&#xff1a; maven-central: 预定义的代理Maven Central仓库&#xff0c;它包含了大量的开源Java依赖包。maven-public: 存储库是一个组合存储库&#xff0c;它包含了maven-releases和maven-snapshots存储库…

Duplicate keys detected: ‘0‘. This may cause an update error

Duplicate keys detected: ‘0’. This may cause an update error.当遇到该节点内容更新时&#xff0c;会因为重复的key导致无法更新。 该错误&#xff0c;是因为同级节点下存在两个由0开始的key&#xff0c;当遇到该节点内容更新时&#xff0c;会因为重复的key导致无法更新。…