当前位置: 移动技术网 > IT编程>数据库>Mysql > Mysql中事务ACID的实现原理详解

Mysql中事务ACID的实现原理详解

2019年07月19日  | 移动技术网IT编程  | 我要评论

引言

照例,我们先来一个场景~

面试官:"知道事务的四大特性么?"
你:"懂,acid嘛,原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)!"
面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“
你:"我只知道隔离性是怎么做的balabala~~"
面试官:"还是回去等通知吧~"

ok,回到正题。说到事务的四大特性原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability),懂的人很多。但是稍微涉及细节一点,这四大特性在数据库中的实现原理是怎么样的?那就没有几个人能够答得上来了。因此,我们这篇文章着重讨论一下四大特性在mysql中的实现原理。

正文

我们以从a账户转账50元到b账户为例进行说明一下acid,四大特性。

原子性

根据定义,原子性是指一个事务是一个不可分割的工作单位,其中的操作要么都做,要么都不做。即要么转账成功,要么转账失败,是不存在中间的状态!

如果无法保证原子性会怎么样?

ok,就会出现数据不一致的情形,a账户减去50元,而b账户增加50元操作失败。系统将无故丢失50元~

隔离性

根据定义,隔离性是指多个事务并发执行的时候,事务内部的操作与其他事务是隔离的,并发执行的各个事务之间不能互相干扰。

如果无法保证隔离性会怎么样?

ok,假设a账户有200元,b账户0元。a账户往b账户转账两次,金额为50元,分别在两个事务中执行。如果无法保证隔离性,会出现下面的情形


如图所示,如果不保证隔离性,a扣款两次,而b只加款一次,凭空消失了50元,依然出现了数据不一致的情形!

ps:可能有细心的读者已经发现了,mysql中是依靠锁来解决隔离性问题。嗯,我们后面来说明。

持久性

根据定义,持久性是指事务一旦提交,它对数据库的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

如果无法保证持久性会怎么样?

在mysql中,为了解决cpu和磁盘速度不一致问题,mysql是将磁盘上的数据加载到内存,对内存进行操作,然后再回写磁盘。好,假设此时宕机了,在内存中修改的数据全部丢失了,持久性就无法保证。

设想一下,系统提示你转账成功。但是你发现金额没有发生任何改变,此时数据出现了不合法的数据状态,我们将这种状态认为是数据不一致的情形。

一致性

根据定义,一致性是指事务执行前后,数据处于一种合法的状态,这种状态是语义上的而不是语法上的。
那什么是合法的数据状态呢?

ok,这个状态是满足预定的约束就叫做合法的状态,再通俗一点,这状态是由你自己来定义的。满足这个状态,数据就是一致的,不满足这个状态,数据就是不一致的!

如果无法保证一致性会怎么样?

例一:a账户有200元,转账300元出去,此时a账户余额为-100元。你自然就发现了此时数据是不一致的,为什么呢?因为你定义了一个状态,余额这列必须大于0。

例二:a账户200元,转账50元给b账户,a账户的钱扣了,但是b账户因为各种意外,余额并没有增加。你也知道此时数据是不一致的,为什么呢?因为你定义了一个状态,要求a+b的余额必须不变。

实战解答

问题一:mysql怎么保证一致性的?

ok,这个问题分为两个层面来说。

从数据库层面,数据库通过原子性、隔离性、持久性来保证一致性。也就是说acid四大特性之中,c(一致性)是目的,a(原子性)、i(隔离性)、d(持久性)是手段,是为了保证一致性,数据库提供的手段。数据库必须要实现aid三大特性,才有可能实现一致性。例如,原子性无法保证,显然一致性也无法保证。

但是,如果你在事务里故意写出违反约束的代码,一致性还是无法保证的。例如,你在转账的例子中,你的代码里故意不给b账户加钱,那一致性还是无法保证。因此,还必须从应用层角度考虑。

从应用层面,通过代码判断数据库数据是否有效,然后决定回滚还是提交数据!

问题二: mysql怎么保证原子性的?

ok,是利用innodb的undo log。

undo log名为回滚日志,是实现原子性的关键,当事务回滚时能够撤销所有已经成功执行的sql语句,他需要记录你要回滚的相应日志信息。

例如

  • (1)当你delete一条数据的时候,就需要记录这条数据的信息,回滚的时候,insert这条旧数据
  • (2)当你update一条数据的时候,就需要记录之前的旧值,回滚的时候,根据旧值执行update操作
  • (3)当年insert一条数据的时候,就需要这条记录的主键,回滚的时候,根据主键执行delete操作

undo log记录了这些回滚需要的信息,当事务执行失败或调用了rollback,导致事务需要回滚,便可以利用undo log中的信息将数据回滚到修改之前的样子。

ps:具体的undo log日志长啥样,这个可以写一篇文章了。而且写出来,看的人也不多,姑且先这么简单的理解吧。

问题三: mysql怎么保证持久性的?

ok,是利用innodb的redo log。

正如之前说的,mysql是先把磁盘上的数据加载到内存中,在内存中对数据进行修改,再刷回磁盘上。如果此时突然宕机,内存中的数据就会丢失。

怎么解决这个问题?

简单啊,事务提交前直接把数据写入磁盘就行啊。

这么做有什么问题?

  • 只修改一个页面里的一个字节,就要将整个页面刷入磁盘,太浪费资源了。毕竟一个页面16kb大小,你只改其中一点点东西,就要将16kb的内容刷入磁盘,听着也不合理。
  • 毕竟一个事务里的sql可能牵涉到多个数据页的修改,而这些数据页可能不是相邻的,也就是属于随机io。显然操作随机io,速度会比较慢。

于是,决定采用redo log解决上面的问题。当做数据修改的时候,不仅在内存中操作,还会在redo log中记录这次操作。当事务提交的时候,会将redo log日志进行刷盘(redo log一部分在内存中,一部分在磁盘上)。当数据库宕机重启的时候,会将redo log中的内容恢复到数据库中,再根据undo log和binlog内容决定回滚数据还是提交数据。

采用redo log的好处?

其实好处就是将redo log进行刷盘比对数据页刷盘效率高,具体表现如下

  • redo log体积小,毕竟只记录了哪一页修改了啥,因此体积小,刷盘快。
  • redo log是一直往末尾进行追加,属于顺序io。效率显然比随机io来的快。

ps:不想具体去谈redo log具体长什么样,因为内容太多了。

问题四: mysql怎么保证隔离性的?

ok,利用的是锁和mvcc机制。还是拿转账例子来说明,有一个账户表如下

表名t_balance

id user_id balance
1 a 200
2 b 0

其中id是主键,user_id为账户名,balance为余额。还是以转账两次为例,如下图所示

至于mvcc,即多版本并发控制(multi version concurrency control),一个行记录数据有多个版本对快照数据,这些快照数据在undo log中。

如果一个事务读取的行正在做delele或者update操作,读取操作不会等行上的锁释放,而是读取该行的快照版本。

由于mvcc机制在可重复读(repeateable read)和读已提交(read commited)的mvcc表现形式不同,就不赘述了。

但是有一点说明一下,在事务隔离级别为读已提交(read commited)时,一个事务能够读到另一个事务已经提交的数据,是不满足隔离性的。但是当事务隔离级别为可重复读(repeateable read)中,是满足隔离性的。

总结

本文讲了mysql中事务acid四大特性的实现原理,希望大家有所收获。

好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对移动技术网的支持。

如对本文有疑问, 点击进行留言回复!!

相关文章:

验证码:
移动技术网