大家好,我是北漂程序员,欢迎关注公众号:北漂程序员
问题:请讲下mysql的事务是如何实现的
分析:该问题主要考察对事务的理解及实现方式;
回答要点:
主要从以下几点去考虑,
1、对事务的概念的理解?
2、事务的实现方式?
讲到mysql的事务,很快可以想到事务的4大特性,那就是ACID,具体说来就是原子性、一致性、隔离性、持久性。也就是说事务就是围绕这4个特性来展开的。其中隔离性中又定义了隔离级别,有读未提交、读已提交、可重复度、可串行化这样4个级别。
对于事务的4个特性,原子性、一致性、持久性说的都是mysql的可靠性方面的考量,对应隔离性说的则是在并发场景下,同时有读和写的情况如何做到数据隔离,到底数据要隔离到什么程度,则就有了隔离级别的概念。
mysql要保证事务的4大特性,主要使用了日志(redo log、undo log)、锁技术、MVCC技术
日志
说到日志,平时接触最多的是mysql的binlog日志,主要用来记录mysql执行的更新语句,用在主从复制的场景比较多。今天来说的日志却不包含binlog,今天来说redo log和undo log
redo log
又叫重做日志,用来实现事务的持久性,包含重做缓冲区和重做日志文件两部分,前者在内存中,后者在磁盘。mysql在事务提交前会把所有的修改信息都记录在redo log中。
为什么要引入redo log那,原来mysql为了提高性能不会把每次的修改都实时同步到磁盘中,而是先存到buffer pool中,然后后台有一个线程来进行buffer pool和磁盘之间的同步。这样就存在一个问题,如果还没来得及进行buffer pool和磁盘的同步,机器宕机了怎么办,那么数据岂不是要丢失,为了解决这个问题,引入了redo log,在事务开始时把修改记录到重做缓冲区,在事务提交前将重做缓冲区的内容刷到磁盘上,不禁要问这不是多此一举吗,我实时把buffer pool中的内容写入磁盘不也可以达到这样的目的,哈哈,肯定不是这样的,因为redo log的文件是顺序写,而buffer pool和磁盘的写是随机写,顺序写的速度要比随机写快很多,所以这就是引入redo log的目的。
undo log
又叫回滚日志,用来保证事务的原子性。用来记录数据被修改前的信息,和redo log正好相反,redo log是记录修改以后的记录。undo log记录的是数据的逻辑变化,为了在发生错误时进行数据的回滚操作。
锁技术
当多个请求同时到达mysql服务器,如果都是读请求,那么可以不采取任何的措施,如果既有读请求又有写请求的前提下,必须要有一种机制来规范读写请求,不然很容易造成数据的不一致,这时就有了锁机制,使用读锁和写锁进行控制即可,读锁对所有的读操作都是共享的,不会造成阻塞;写锁则是排他锁,不能做到写读、写写并行。
MVCC
MVCC叫做多版本并发控制,通过在每条记录的后边保存两个隐藏的列来实现,一个保存行创建的时间,一个保存行的过期时间,保存的不是时间而是系统版本号,通过MVCC来做到读写分离。
在事务的4大特性中隔离性是最复杂的,4种隔离级别分别定义了一个事务种的修改哪些是事务之间可见的,哪些是事务之间不可见的。
读未提交
读未提交是读的情况下不加任何的锁,所以会读到其他事务未提交的数据,造成脏读数据
读已提交
在该隔离级别下,读操作是不加锁的,采用MVCC的方式进行读取;写操作加排他锁,也就是写锁。该级别会产生不可重复读和幻读的情况。
不可重复读指的是两次的读数据内容发生了变化,行数未变,针对update操作;幻读是两次的读数据内容未变,行数发生了变化,针对insert、delete操作;
在读已提交隔离级别下实现的MVCC机制是这样的,每次的select操作都会生成一个新的版本号,所以每次的读取都是不同的副本,那么就存在不可重复读和幻读
可重复读(mysql默认隔离级别)
在一个事务中多次的读取结果是一样的。有两种机制可以实现这种效果,分别是读写锁和MVCC。
使用读写锁实现的话,优点是实现简单,但是读写无法并行。
使用MVCC机制实现优点是实现复杂,但读写可并行。在这种情况下实现的MVCC,每次的select操作都是使用最开始的版本号,所以每次的读取都是相同的数据,不会产生不可重复读,但是会产生幻读的情况,mysql通过next-key锁(行锁+间隙锁)的方式解决了幻读。
参考:https://www.sohu.com/a/316482862_663371
https://www.cnblogs.com/zhiqian-ali/p/5668199.html