背景
数据入库这块有离线和实时两套入库系统,写同一个db的同一批mysql表,两边用的都是insert into table on duplicate key update这种方式。实时一直运行,离线5分钟更新一次,当两套系统同时运行时出现了死锁问题,频率还挺高。事务的隔离级别是read committed 读提交。
原因分析&解决方案
这里面分两种情况,一种是带主键的insert duplicate key update,一种是没有主键带唯一索引的insert duplicate key update。
1、带主键的insert duplicate key update
实时入库的batch大小是1w,离线入库的batch大小也是1w,为了提高入库效率 ,两边都开启了事务。当两边同一批插入的数据中包含了相同的数据,且顺序不一致,此时会出现死锁。比如说实时任务当前插入的数据包含id为1,2的数据,离线任务当前插入的数据包含2,1。此时实时任务获取了id为1数据的锁,等2的数据锁,离线任务获取了id为2的数据锁,等id为1数据锁,产生了死锁。
这种情况比较简单,处理方式有两种:
1、减少batch大小,减少了同一批数据中包含相同数据的概率,也就减少了死锁发生的概率
2、入库前对sql按照id排序,即使出现相同数据,只要保证顺序相同就不会出现死锁
2、带唯一索引的insert duplicate key update
https://developer.aliyun.com/article/727076 这篇文章讲的很清楚,这里我大致聊一下。
insert相关的有四种锁。
- record锁,也就是锁一条记录,这时其他事务读写不了当前加锁的记录。
- gap锁,锁一个区间。比如说db中有1,3,5,那么对应的区间就有(-∞,1),(1,3),(3,5),(5,+∞),该锁可以锁住上面四个区间的任何一个或者多个。
- next-key锁,锁一条记录和小于该记录最近的一个gap,本质上就是record锁加上gap锁。比如说db中有1,3,5,那么对应的区间就有(-∞,1],(1,3],(3,5],(5,+∞],该锁可以锁住上面四个区间的任何一个或者多个。
- Insert Intention锁(插入意向锁):这个锁是在数据插入之前会加此锁。它是一种轻量的Gap锁,同时也是意向排他锁的一种。它的存在使得多个事务在写入不同数据到统一索引间隙的时候,不会发生锁等待。
插入唯一索引时判断索引是否存在。如果不存在,会在数据所属的gap添加Insert Intention锁。由于意向锁是轻量gap锁,这时即使有同gap的其他数据插入,两者之间不会互相影响。
如果插入的索引已经存在,会在索引值位置插入next-key锁。next-key锁包含record锁和gap锁,gap锁会锁一个范围,锁住期间,其他事务不能向该范围插入数据。如果此时两个事务各自获取到了一个next-key锁,此时都需要向对方获取到的next-key锁范围插入数据,就会出现死锁。
举例:
code字段有唯一索引。初始数据:insert into test2 (code, other) values(1,1),(3,3),(5,5)
事务1:
insert into test2(code,other)values(3,3) on duplicate key update other=values(other);
由于code为3的数据已经存在,所以会在(1,3]这个范围加next-key锁。
事务2:
insert into test2(code,other)values(5,5) on duplicate key update other=values(other);
由于code为5的数据已经存在,所以会在(3,5]这个范围加next-key锁。
如果此时事务1插入一条code为4的数据,那么此时会等待事务2 (3,5]的next-key锁释放;
如果同时事务2插入一条code为2的数据,那么此时会等待事务1 (1,3]的next-key锁释放;
形成死锁。
解决方案:
1、减少batch的大小,单个事务获取到的next-key锁的范围就会变少,减少死锁的概率。
2、重试。
3、插入数据时添加主键。如果插入数据时带上主键,那么就不会产生next-key锁,会退化到第一种情况(带主键的insert duplicate key update)。
网友评论