0
点赞
收藏
分享

微信扫一扫

利用HubSpot出海CRM和人工智能技术提升出海业务的效率和效果

eelq 2天前 阅读 1

什么是MVCC?

MVCC全称 Multi-Version Concurrency Control,即多版本并发控制,维持一个数据的多个版本,主要是为了提升数据库的并发访问性能,用更高性能的方式去处理数据库读写冲突问题,实现无锁并发。

什么是快照读和当前读?

  • 快照读:不加锁非阻塞读,快照读要求数据库隔离级别不能是串行化,否则会退化到当前读,快照读是基于多版本并发控制的,因为是基于多版本并发控制,所以快照读可能读取的不是最新的数据。
  • 当前读:当前读就是读取最新的数据版本,快照读读取的时候,会对读取的数据加锁,读取的时候其他事务不能修改当前数据。

MVCC和快照读、当前读的关系?

MVCC 多版本并发控制,而快照就是数据的一个版本,MVCC 的无锁并发就是依赖快照读机制实现的。

MVCC的实现原理?

MVCC 实现依赖于数据库记录中的三个隐式字段、undo日志、Read View 版本链,本篇讨论皆基于 MySQL 的 InnoDB 存储引擎。

三个隐式字段:

隐式字段,是我们正常来看看不到的字段,数据库的每行数据除了我们看到的字段之外,还有三个我们看不到的字段。

  • DB_TRX_ID:记录当前事务最后一次修改的事务ID,即事务 ID,事务 ID 是递增的。
  • DB_ROW_ID:隐藏的自增主键ID,如果数据库没有主键ID,数据库会自动生成一个 6个字节的 DB_ROW_ID。
  • DB_ROLL_PTR:回滚指针,指向上一个数据版本。

简单图例:

在这里插入图片描述

undo log 日志:

我们都知道undo log 日志是回滚日志,是数据库保证数据一致性的一个支撑,当出现异常情况时候,通过 undo log 日志来进行数据回滚,其实它还有其他作用,undo log 又分为两种,如下:

  • insert undo log,insert 操作时候产生的日志,只会在发生异常需要进行回滚的时候使用,事务提交后,undo log 就没有用处了,就会被丢弃。
  • update undo log 和 delete undo log,这两类 undo log 不仅在事务回滚时候要用到,同时在快照读的时候也会用到。

undo log 也会记录一条版本链表,每次修改数据的时候,数据库会先把当前数据拷贝一份到 undo log中,然后再对数据进行修改,最在undo log 中最新修改的数据副本会在链的头部,同时它有一个回滚指针指向他的上一个版本。

Read View:

Read View 是事务执行快照读产生的视图,在事务执行快照读的时候,系统会以当前时刻生成一个快照,以此来维护系统此时活跃的事务id,用来做可见性判断,当某个事务进行快照读的时候,我们根据 Read View 来判断当前事务可以读取哪个版本的数据,然后就去该数据的 undo log 里面找数据,当然也可能是读取最新的数据。

Read View 遵守可见性规则,它的三个属性如下:

  • trx_list:用来维护 Read View 生成时候系统活跃的事务ID,是一个列表。
  • up_limit_id:活跃事务ID中最小的ID。
  • low_limit_id:Read View 生成时候,系统将要分配的下一个事务ID。

Read View 的比较流程如下:

注意事务ID 是递增的。

  • 第一步,比较 DB_TRX_ID < up_limit_id, 是否小于活跃事务 Read View中最小的事务ID,如果小于,则当前事务能看到 DB_TRX_ID 所在的记录,否则进入第二个判断。
  • 第二步,比较 DB_TRX_ID >=low_limit_id, 是否大于等于下一个将要发生的事务ID,如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View生成后才出现的,那对当前事务肯定不可见,否则进入第三个判断。
  • 第三步, 判断 DB_TRX_ID 是否在活跃事务 Read View 之中,如果在,则代表我 Read View 生成时刻,你这个事务还在活跃,还没有Commit,你修改的数据,我当前事务也是看不见的,如果不在,则说明,这个事务在 Read View 生成之前就已经 Commit 了,因为第一步、第二步已经判断了是否小于最小活跃事务ID和是否是将要发生的事务ID,两者都不是,同时又不在 活跃事务 Read View 中,只能说明在这个事务 Read View 在当前是事务发生之前了,当前事务理所当然能够看到。

简易流程如下:

在这里插入图片描述

读已提交(Read Committed)、可重复读(Repeatable Read) 隔离级别下的快照读的区别?

读已提交(Read Committed)、可重复读(Repeatable Read) 隔离级别下的快照读最大的区别就是生成 Read View 时机不同。

  • 可重复读(Repeatable Read) 隔离级别下,一个事务只有在第一次读取数据的时候生成一个Read View,Read View 记录当前活跃的事务ID,后面继续读取数据时候,如果用到快照读,那他使用的还是第一次读取时候的 Read View,这也是为什么可重复读(Repeatable Read) 隔离级别下,看不到别的事务的修改记录的原因。
  • 读已提交(Read Committed) 隔离级别下,事务开启后,每次使用快照读的时候,都会重新生成一个活跃事务ID,第一读取和第二次读取使用的不是同一个 Read View,那第二次读取的时候,第一次读取时候的 Read View 中的某些事务可能已经提交了,那在第二次快照读的时候就可以看到了,这也是在读已提交(Read Committed) 隔离级别下可以看到别的事务提交的记录的原因 。

MVCC解决了什么问题?

想要知道MVCC解决了什么问题,我们要先知道数据库多个事务并发访问会有什么问题,数据库并发访问场景如下:

  • 读读并发:多个事务同时读取同一份数据,不存在问题,无需进行并发控制。
  • 读写并发:多个事务同时读写同一份数据,有线程安全问题,可能会脏读、幻读、不可重复度问题。
  • 写写并发:多个事务同时对同一份数据写,可能会有更新丢失的情况。

而MVCC 就是解决以上三种并发中的读写并发问题,是一种无所并发控制,可以解决脏读、不可重复读问题,可以解决部分场景的幻读问题。

什么是幻读?MVCC可以解决幻读问题吗?

MVCC 可以解决快照读的幻读问题,MVCC 机制是依赖 快照读、undo log、Read View 来实现的,可以解决快照读的幻读问题,但是不能解决 update、delete 的幻读问题,因为这些操作是当前读。

以下讨论基于可重复读(Repeatable Read) 隔离级别。

当前读幻读演示:

时间事务A事务B
1开始事务
2第一次查询:select * from user where id > 1;
3开始事务
4执行insert: INSERT INTO user(id, user_name, user_code, age, address, hobby)VALUES(6, ‘赵六’, ‘TC-00000006’, 26, ‘广西’, ‘羽毛球’);
5提交事务
6第二次查询:select * from user where id > 1;
7修改数据:update user set name = ‘赵六国’ where id = 6;
8第三次查询:select * from user where id >1;
9提交事务

流程解释:

  • 在第2个时间点的时候,快照读,可以得到 id 大于 1的数据。
  • 在第6个时间点的时候,虽然时间点4插入了一条 id 为6的数据,并且在时间点5提交了事务,但是时间点6还是查询不到 id 为6的这条数据,查询结果和第2个时间点的查询结果没有区别。
  • 在第7个时间点的时候,查询结果就有了变化,因为 update 操作是当前读,而事务B在第5个时间点已经提交了一条 id 为6的数据,根据当前读的规则,此刻是可以读取到 id 为6 的数据,也就可以更新 id 为 6 的数据。
  • 第8个时间点的时候,执行第三次查询,此时是基于当前最新版本查询的,所以会查询到事务B提交的 id 为6的数据,对比第一次、第二次查询,多出了 id 为6的数据,这就是幻读

当前读的幻读问题怎么解决?

加锁解决,关于锁的介绍,传送门如下:

MySQL–锁机制详解

#共享锁
SELECT * FROM user LOCK IN SHARE MODE;  
# 排他锁
SELECT * FROM user FOR UPDATE; 
# 排他锁
INSERT INTO  user 
# 排他锁
UPDATE user 
# 排他锁
DELETE FROM  user 

注意:INSERT、UPDATE 、DELETE 操作数据库默认加排他锁。

解决幻读问题演示:

时间事务A事务B
1开始事务
2第一次查询:select * from user where id > 5 lock in share mode;
3事务A显示加了间隙锁
4开始事务
5执行insert: INSERT INTO user(id, user_name, user_code, age, address, hobby)VALUES(6, ‘赵六’, ‘TC-00000006’, 26, ‘广西’, ‘羽毛球’);
6阻塞了,处于等待状态
7select * from user where id > 5
8提交事务
9事务A提交了,释放了间隙锁,事务B 执行 INSERT 操作
10提交事务
  • 在第2个时间点的时候,使用 lock in share mode 语法显示加锁了,不仅表中存在的数据加锁了,而且还给 id>5 的区间加了间隙锁
  • 因为时间点2的操作,给 id>5 的区间加了间隙锁 ,所以事务B 在时间点5的时候执行 INSERT 操作的时候,出现了阻塞。
  • 因为时间点5的 INSERT 操作被阻塞了,所以这次查询的数据跟时间点2的查询结果完全一致。
  • 事务B想要执行 INSERT 成功,必须要等待事务A 提交事务释放锁,这就解决了幻读问题。

MVCC可以解决更新丢失问题吗?

MVCC 解决的是读写并发问题,而更新丢失是写写并发问题,MVCC不能解决更新丢失问题,更新丢失依赖数据库的隔离级别来解决。

如有不正确的地方请各位指出纠正。

举报

相关推荐

0 条评论