面试必备——MySQL的ACID实现原理

文章目录

  • 1 问题背景
  • 2 事务
  • 3 原子性
  • 4 持久性
    • 4.1 redo log的存在背景
    • 4.2 为什么将redo log的数据写到磁盘比将Buffer中的数据写到磁盘快?
    • 4.3 redo log什么时候同步到磁盘里去?
  • 5 隔离性
    • 5.1 含义
    • 5.2 情况
  • 6 总结

1 问题背景

前面用sql语句演示了MySQL锁导致的现象,从现象去认知了MySQL锁到底是怎么样的。在本博客MySQL高级系列的文章中也有研究过InnoDB引擎的架构。今天来串联一下InnoDB引擎的架构以及MySQL事务、MySQL锁的知识。

参考自:MySQL事务ACID实现原理

2 事务

如下所示:

start transaction
待执行的若干个sql语句
commit

MySQL默认自动提交事务。start transaction是开启一个事务,接着执行待执行的若干个sql语句,最后使用commit提交。如果没有commit,那么事务就永远不会提交。

3 原子性

概念:原子性是指一个事务是一个不可分割的单位,是一个最小的操作单元,这个操作单元包含若干个操作(一个sql就是一个操作)。这些若干个操作要么全部成功,要么全部失败。

如果一个事务中的一个sql语句执行失败,那么已经执行的sql语句需要执行回滚,回滚到事务执行前的状态。它的实现原理就是undo log。

MySQL中的日志有很多,比如undo log、redo log、bin log、错误日志、慢查询日志、查询日志。InnoDB引擎提供了两种事务的日志,分别是undo log和redo log

原子性的体现就是体现在回滚上面。如果事务中的某个sql报错会执行回滚。回滚到执行事务之前的状态。因此我们要把执行事务之前的状态记录下来,如果一旦sql语句发生错误,就可以通过执行事务前记录下来的状态信息,回滚到执行事务之前的状态。其实这种原理思想也体现在日常迭代上线的流程中。如果程序上线失败、上线过程中遇到不可知的错误或不能立刻解决的bug,此时需要回滚上线版本,把版本回滚到上一个正常的版本。这与undo log的原理是相通的,就是要记住正确的版本是什么。(用日常迭代上线的例子只是简单解释undo log的思想,日常迭代上线有很多种解决方案,笔者记得有ab发布、蓝绿发布、灰度发布等)。

当事务对数据进行修改的时候,innodb会生成对应的undo log,他会记录每条sql执行的相关信息。如果sql执行失败,innodb会根据undo log的信息执行相反的操作来回滚,比如某一个事务中的某个sql是执行insert操作,那么回滚的时候会执行delete操作。对于delete操作,会执行一个insert操作。对于update操作,会执行相反的update操作。这些相反的操作的执行都基于这个undo log,要把sql的执行信息记录到undo log里面,回滚的时候就根据undo log 去回滚。

4 持久性

概念:持久性是指一个事务一旦提交,它对数据库的改变是永久性的。持久性也是通过一个log来实现,它叫redo log。

4.1 redo log的存在背景

MySQL数据是存在磁盘中的,如果每次读取数据都去磁盘读取则会有一个磁盘IO的过程,那么它的效率会很低。因此InnoDB提供了一个缓存Buffer,该Buffer包含磁盘中部分的数据页的一个映射,作为访问数据库的一个缓冲。当从数据库读取数据,会先从这个Buffer中读取,如果Buffer中没有则会从磁盘中取,读取完才会放在这个Buffer缓存中。当向数据库写入数据的时候,也会先向该Buffer中写入数据,并将Buffer中的数据刷新到磁盘中。但是这时存在一个问题,虽然读写效率提升了,但是如果Buffer中的数据还没来得及同步到磁盘上,此时MySQL宕机了,那么Buffer中的数据就会丢失掉,进而造成数据的丢失。数据丢失了,事务的持久性也就无法保证了。因此redo log就被引入进来解决这个问题。改进后的流程变为:当数据库的数据要进行新增或修改的时候,除了修改Buffer中的数据,还要把这次的操作记录到redo log里面。如果MySQL宕机了,还可以从redo log恢复数据。redo log是一个预写式日志,指它会将所有的修改先写入到日志里面,再更新到Buffer里面(笔者认为此思想与Java更新缓存的方式相通,都是先写库再更新缓存),保证了数据不会丢失。

4.2 为什么将redo log的数据写到磁盘比将Buffer中的数据写到磁盘快?

有两个原因。

  1. Buffer中的数据持久化是随机写的IO。每次修改的数据位置都是随机的。但是redo log是追加模式的,它是在文件的尾部追加,属于一种顺序IO的操作。这种方式就很快。KafKa也是采用顺序IO机制操作的。

  2. Buffer持久化数据是以数据页page为单位的,MySQL默认配置大小为16k,一个数据页上一个小小的数据修改,都需要把整个页的数据写入。而redo log只需要写入真正的部分即可。这个无效的IO就大大减小了。所以redo log比Buffer同步数据要快很多很多。

4.3 redo log什么时候同步到磁盘里去?

redo log没有同步到磁盘之前是在缓存区中,它叫redo log缓冲区。MySQL宕机也没有关系,因为事务没有执行完,即事务没有提交,恢复好数据库后可以通过undo log走回滚操作。redo log的持久化机制可以通过innodb_flush_log_at_trx_commit

  • 值为0时,表示当事务提交时,并不将缓冲区的redo log写入到磁盘的日志文件,而是等待主线程每秒刷新
  • 值为1时,表示当事务提交时将缓冲区中的redo log 同步写入 到磁盘中, 保证一定会写入成功 。同步写入的速度很快,比Buffer同步快很多。
  • 值为2时,表示事务提交时将缓冲区的redo log 异步写入 到磁盘中。不能保证在commit时一定会将redo log写入磁盘中去。

5 隔离性

5.1 含义

不同事务之间不能相互影响。

5.2 情况

  1. 写-写操作,通过解决
  2. 写-读操作,通过MVCC解决。写读操作会产生幻读、脏读、不可重复读

写-写的情况:

InnoDB的锁大致分为行锁、表锁、间隙锁。若干事务对同一行进行操作,那么此时只能有一个事务对数据进行操作,那么这个需要由锁来保证。锁能保证在同一时刻只有一个人在操作数据。事务在修改数据之前,这个事务需要获取到相应的锁,获取到之后该事务就可以修改数据了。如果其他事务想要修改事务,那么必须要等到拿到锁的事务提交事务或者回滚后释放锁,下一个事务才能来抢这个锁去执行事务。

写-读操作的情况:

通过四个隔离级别解决。后续会详细讲解并写成博客。

6 总结

原子性:

一个事务内的sql语句要么全部执行,要么全不执行,是通过undo log原理实现的。

一致性:

一致性是指事务执行之后,数据库的完整性约束没有被破坏,事务执行前后都是一个合法的数据状态。他的完整性主要体现在数据库主键要唯一,字段的类型、大小、长度、外键约束要符合要求。一致性是事务追求的最终目标,ACID中三种特性都是为了实现最终的一致性。

隔离性:

写-写操作主要是通过锁实现的。如果是读- 写操作则是通过mvcc。

持久性:

通过redo log保证的

你可能感兴趣的:(Java面试题笔记,MySQL高级,面试,MySQL)