你真的明白数据一致性吗—— max(id) 破坏 Mysql 事务一致性

哒哒队长

场景

业务中有一个日志表,插入数据与同步数据查询强依赖于主键的有序性

数据同步时携带上次同步更新的主键,查询到Max(id)之间的数据,只同步增量部分

意味数据只有一次同步机会

表结构如下
表.png

问题

Mysql 数据隔离级别是RR

讲道理,两个不同的事务来读取数据后一个事务 B 是无法读取的到先一个事务 A 数据的数据

但是我们这里有个逻辑很特殊Max(id)

这里有两个场景:

A先读,B后写

假设目前数据最后一条记录是3

A事务携带上次同步主键2来请求,Max(id) = 3

这时B事务前来写数据

A事务先于B事务,根据 Mysql MVCC 视图,查询到了id=2,id=3的数据

同时B事务,写入数据id=4,id=5

下次数据同步携带id=3,继续走,业务无误

图示:

先读后写.png

AC先写,B后读

假设目前数据最后一条记录是3

A事务开始写入4

C事务开始写入5

事务还没有结束时,B携带2来读

期望同步2~3之间的数据,实际上却读到了2~5,但是实际上可读的数据还是1 2 3

这是为什么呢?

这就牵扯到了InnoDB 主键自增的规则了

InnoDB 的每个表的自增主键都,保存在内存中

偏移量:auto_increment_offset

步长:auto_increment_increment

默认双1

插入数据时获取该值,+后写入1

因为事务A耗时长,事务C耗时短

导致事务 C 先于事务 A提交

就种情况就是对业务有损了!!

4 数据就被永远的丢失了,阿西吧!!!

天知道我查了多久啊!!!

图示:
先写后读png.png

解决方案

1.间隙锁

在数据同步查询前加上select max(1) from table for update;增加间隙锁

阻塞读写,但是会有性能瓶颈

注意:间隙锁的范围要控制好

BadCase

1.select * from table limit 1 for update;

本意是只想锁住(max-1,max](max,sumpernum],减少锁间隙

但是忘记主键索引默认正向有序,这样其实是锁住了(-supernum,1](1,2]

正确的写法是:select * from table order by desc limit 1 for update;

2.select max(1) from table for update;

这种写法虽然满足了锁住表的要求,但是锁的是主键索引,也就是全表

当时考虑1会增加一次 Mysql 运算,希望节省性能,但是这样并发就下去了

2.分布式读写锁

以上的问题经过分析后都不是最好的方案,最后修改为分布式读写锁,具体方案见下一篇文章

阅读 1.7k

7 声望
0 粉丝
0 条评论
7 声望
3 粉丝
宣传栏