7 mysql事务(包括redo log,undo log,MVCC)及事务实现原理

之前写了几篇mysql存储原理的文章。

6 Innodb_buffer_pool

b+ tree和每个page存储结构

4 innodb文件系统基本结构(段、簇、页面)

innodb文件系统初步入门

表对象缓存

1 连接层

这一篇终于到事务了,事务大家都知道ACID概念,那么mysql是如何完成事务的呢?

先来看结论——

原子性:

一次事务中的所有操作,要么全部完成要么全部不执行。这里是通过undo log来实现的。

undo log又是什么呢,可以理解为要执行的sql的反向sql,也就是回滚sql。譬如你insert了一条,undo log里就会保存一个delete xxx id = xxx。

持久性:

一旦一个事务被提交,就算服务器崩溃,仍然不能丢数据,在下次启动时需要能自动恢复。这里是通过redo log实现的。

那么如何才能持久呢,很简单,写入硬盘就行了。通过前面几篇的学习,我们知道mysql大部分时间是在Innodb_buffer_pool里做内存读写的,特定情况下才会落盘。这样如果突然服务器崩溃,没来得及落盘的数据就会丢失。所以有了redo log顺序写磁盘(顺序写速度极快,后续的落盘是随机写,速度慢),在事务提交后,事务日志会顺序写入磁盘,然后写入pool内存里。然后才是后续的那些按规则将索引数据落盘。

隔离性:

事务的隔离性是通过读写锁+MVCC来实现的。mysql在为了并发量和数据隔离方面做了很多的尝试,其中MVCC就是比较好的解决方案。

也就是面试最常见的4大隔离级别。

       1.读未提交          其它事务未提交就可以读
       2.读已提交          其它事务只有提交了才能读
       3.可重复读          只管自己启动事务时候的状态,不受其它事务的影响(mysql默认)
       4.事务串行          按照顺序提交事务保证了数据的安全性,但无法实现并发

一致性:

即数据一致性,是通过上面的三种加起来联合实现的。

ACID只是个概念,最终目的就是保证数据的一致性和可靠不丢。

 

Undo Log

所谓的undo log就是回滚日志,当进行插入、删除、修改操作时,一定会生成undo log,并且一定优先于修改后的数据落盘

我直接借用别人的图了,zhangsan的银行账户有1000元,他要转400元到理财账户。

可以看到,每一条变更数据的操作,都伴随一条undo log的生成。undo log就是记录数据的原始状态。这一点在一些其他的分布式事务的框架里也有所使用,譬如seata就是采用自己解析sql并生成反向sql存储下来,将来抛异常时就执行回滚语句的方式来做的分布式事务,而不借助于mysql自身的undo log机制。

有了undo log,如果事务执行失败要回滚,那很简单,直接将undo log里的回滚语句执行一遍就好了。mysql就是通过这种方式完成的原子性。

Redo Log

redo log是完成数据持久性的,事务一旦提交,其所做的修改就会永久保存到数据库中,而不能丢失,即便是mysql服务器挂掉了也不能丢。

mysql数据是存储到磁盘的,但读写其实都是操作的buffer pool缓存(前面几篇讲过insert buffer)。这样就会造成写入时,如果仅仅写入到buffer pool了,还没来得及刷入数据页,那么mysql突然宕机,就会丢失数据。

此时redo log的作用就出来了,在写入buffer pool后会同时写入到redo log(顺序写磁盘)一份,redo log有固定的大小,会被重复使用。

MVCC及隔离级别

mvcc是什么

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。理解为:事务对数据库的任何修改的提交都不会直接覆盖之前的数据,而是产生一个新的版本与老版本共存,使得读取时可以完全不加锁。

有点抽象是吗,再来详细解释一下。同一行数据会有多个版本,某事务对该数据的修改并不会直接覆盖老版本,而是产生一个新版本和老版共存。然后在该行追加两个虚拟的列,列就是进行数据操作的事务的ID(created_by_txn_id),是一个单调递增的ID;还有一个deleted_by_txn_id,将来用来做删除的。

那么在另一个事务在读取该行数据时,由具体的隔离级别来控制到底读取该行的哪个版本。同时,在读取过程中完全不加锁,除非用select * xxx for update强行加锁。

譬如read committed级别,每次读取,总是取事务ID最大的那个就好了。

对于Repeatable read,每次读取时,总是取事务ID小于等于当前事务的ID的那些数据记录。在这个范围内,如果某一数据有多个版本,则取最新的。

MVCC在mysql中的实现依赖的是undo logread view

undo log记录某行数据的多个版本的数据;read view用来判断当前版本数据的可见性。

mysql就是用MVCC来实现读写分离不加锁的。

那么MVCC里多出来的那些版本的数据最终是要删除的,支持MVCC的数据库套路一般差不多,都会有一个后台线程来定时清理那些肯定没用的数据。只要一个数据的deleted_by_txn_id不为空,并且比当前还没结束的事务ID最小的一个还小,该数据就可以被清理掉了。在PostgreSQL中,该清理任务叫“vacuum”,在Innodb中,叫做“purge”。

 

隔离级别

隔离级别目的很明确,管理多个并发读写请求的访问顺序,包括串行和并行,要在并发性能和读取数据的正确性上做个权衡

其中的两个隔离级别Serializable和 Read Uncommited几乎用不上,这里不谈。

Read Committed

能读到其他事务已提交的内容,这是Springboot默认的隔离级别。一个事务在他提交之前的所有修改,对其他事务不可见。提交后,其他事务就能读到了。在很多场景下这种逻辑是可以接受的。

在这个隔离级别下,读取数据不加锁而是使用MVCC机制,写入数据就是排他锁。该级别会产生不可重复读和幻读问题

不可重复读就是在一个事务内多次读取的结果不一样,这个很容易理解,上面讲MVCC时也说了,该级别每次select时都会去读取最新的版本,所以同一个事务内,也就是代码前面一行select了,后面又select了,可能会select到不同的值。因为这两次select过程中,有其他事务对select的行进行了事务提交,就会被select出来最新的。

幻读,即一个事务能够读取到插入的新数据。会出现幻读也是一样的道理,第一次select时还没值,再次select时又有值了。

Repeatable Read

这个级别名字就是可重复读,这是mysql默认的隔离级别。

为什么能重复读,前面讲MVCC时也说了,这个级别下,一旦读到某个版本,后续都是这个版本了,好比是一次快照,就不关心其他事务对该行数据的提交了,它只认第一次读取时的版本号。

这个级别在一些场景下很重要,如

     数据备份:
             例如数据库S从数据库M中复制数据,但是M又不停的在修改数据。S需要拿到M的一个数据快照,但又不能停M。
     数据合法性校验:
             例如有两张表,一张记录了当时的交易总额,另一张记录了每个交易的金额。那么在读取数据时,如果没有快照的存在,交易总额就可能和当时的交易总额对不上。

该级别依然会出现幻读的问题,repeatable是可以出现幻读的,一个事务虽然不能读取其他事务对现有数据的修改,但是能够读取到插入的新数据。

即便是MVCC也解决不了幻读的问题,这里有一篇讲的原因

写前提困境

尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲,在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的:

    先读取一段现有的数据

    在这个数据的基础上做逻辑判断或者计算;

    将计算的结果写回数据库。

这样第三步的写入就会依赖第一步的读取。但是在1和3之间,不管业务代码离得有多近,都无法避免其他事务的并发修改。换句话说,步骤1的数据正确是步骤3能够在业务上正确的前提,这样其实与MVCC都没什么关系了,因为我们想象中的要操作的数据和实际值并不一样,无论怎么步骤3的结果其实都不对了。

无论你用哪种隔离,你都无法解决第一步读取的数据和第三步操作之间,别的事务对它的修改。

解决方法:

结论

虽然上面写了很多,也很复杂,貌似不上锁怎么都难以解决写前提困境。而事实上,我们几乎不用考虑这样的场景,极少有可能说多个客户端同时操作同一条数据,又刚好碰上需要抉择read committed还是Repeatable read的困境。

结论很简单,不管他就好,你几乎没机会碰到这样的选择困境。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 精致技术 设计师:CSDN官方博客 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值