事务原子性、一致性、持久性的实现原理-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

事务原子性、一致性、持久性的实现原理

简介: 云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 前言大家都知道事务有四个特性: 原子性(atomicity)原子性是指整个数据库事务是不可分割的工作单位。

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!


前言

大家都知道事务有四个特性:

  • 原子性(atomicity)

原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行都成功,才算整个事务成功。如果事务中任何一个SQL语句执行失败,那么已经执行成功的SQL语句也必须撤销,数据库状态应该退回到执行事务前的状态。

  • 一致性(consistency)

一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏。

  • 隔离性(isolation)

一个事务的影响在该事务提交前对其他事务都不可见——这通过锁来实现。

  • 持久性(durability)

事务一旦提交,其结果就是永久性的。即使发生宕机等故障,数据库也能将数据恢复。

本篇文章主要讲述其它三个特性是如何实现的:通过数据库的redo和undo来完成。本文如果不做特别说明,默认指的是mysql的InnoDB存储引擎。

实现

基础知识

1.redo log记录的关于每个页(Page)的更改的物理情况。

2.undo log和redo log记录物理日志不一样,它是逻辑日志。可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。

3.LSN称为日志的逻辑序列号(log sequence number),在innodb存储引擎中,lsn占用8个字节。LSN的值会随着日志的写入而逐渐增大。事务中更新操作会产生一个新的LSN。LSN不仅存在于redo log中,还存在于数据页中。

4.checkpoint检查点,表示脏页写入到磁盘的时候。

整体流程

1

无论是日志还是数据,都是现在buffer里修改,然后再同步到磁盘上的。

1.启动事务后,修改的数据如果没有在log buffer中,则会从磁盘读取到log buffer

2.对内存中数据修改之前,将原始数据记录到undo log

3.对内存中的数据页进行修改,在内存数据页中记录LSN,暂且称之为data_in_buffer_lsn

4.在修改数据页的同时(几乎是同时)向redo log in buffer中写入redo log,并记录下对应的LSN,暂且称之为redo_log_in_buffer_lsn;

5.日志刷盘和数据刷盘

日志刷盘的规则为

  • 发出commit动作时
  • 每秒刷一次
  • 当log buffer中已经使用的内存超过一半时
  • 当有checkpoint时
  • 数据刷盘的规则为
  • 当有checkpoint时

日志刷盘的次数比数据刷盘次数更多,另外即使在checkpoint时,innoDB也会保证在写数据前,需要先写日志,这种方式称为预写日志方式(Write-Ahead Logging,WAL)。InnoDB存储引擎通过预写日志的方式来保证事务的完整性。

预写日志方式之所以能保证完整性,是因为日志和数据页中有LSN,通过LSN可以比较日志和数据页中数据记录的顺序。日志文件是真正的核心。

实例

2

上图中,从上到下的横线分别代表:时间轴、buffer中数据页中记录的LSN(data_in_buffer_lsn)、磁盘中数据页中记录的LSN(data_page_on_disk_lsn)、buffer中重做日志记录的LSN(redo_log_in_buffer_lsn)、磁盘中重做日志文件中记录的LSN(redo_log_on_disk_lsn)以及检查点记录的LSN(checkpoint_lsn)。

假设在最初时(12:0:00)所有的日志页和数据页都完成了刷盘,也记录好了检查点的LSN,这时它们的LSN都是完全一致的。

假设此时开启了一个事务,并立刻执行了一个update操作,执行完成后,buffer中的数据页和redo log都记录好了更新后的LSN值,假设为110。这时候如果执行 show engine innodb status 查看各LSN的值,即图中①处的位置状态,结果会是:

log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at

之后又执行了一个delete语句,LSN增长到150。等到12:00:01时,触发redo log刷盘的规则(其中有一个规则是 innodb_flush_log_at_timeout 控制的默认日志刷盘频率为1秒),这时redo log file on disk中的LSN会更新到和redo log in buffer的LSN一样,所以都等于150,这时 show engine innodb status ,即图中②的位置,结果将会是:

log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at

再之后,执行了一个update语句,缓存中的LSN将增长到300,即图中③的位置。

假设随后检查点出现,即图中④的位置,正如前面所说,检查点会触发数据页和日志页刷盘,但需要一定的时间来完成,所以在数据页刷盘还未完成时,检查点的LSN还是上一次检查点的LSN,但此时磁盘上数据页和日志页的LSN已经增长了,即:

log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at

但是log flushed up to和pages flushed up to的大小无法确定,因为日志刷盘可能快于数据刷盘,也可能等于,还可能是慢于。但是checkpoint机制有保护数据刷盘速度是慢于日志刷盘的:当数据刷盘速度超过日志刷盘时,将会暂时停止数据刷盘,等待日志刷盘进度超过数据刷盘。

等到数据页和日志页刷盘完毕,即到了位置⑤的时候,所有的LSN都等于300。

随着时间的推移到了12:00:02,即图中位置⑥,又触发了日志刷盘的规则,但此时buffer中的日志LSN和磁盘中的日志LSN是一致的,所以不执行日志刷盘,即此时 show engine innodb status 时各种lsn都相等。

随后执行了一个insert语句,假设buffer中的LSN增长到了800,即图中位置⑦。此时各种LSN的大小和位置①时一样。

随后执行了提交动作,即位置⑧。默认情况下,提交动作会触发日志刷盘,但不会触发数据刷盘,所以 show engine innodb status 的结果是:

log sequence number = log flushed up to > pages flushed up to = last checkpoint at

最后随着时间的推移,检查点再次出现,即图中位置⑨。但是这次检查点不会触发日志刷盘,因为日志的LSN在检查点出现之前已经同步了。假设这次数据刷盘速度极快,快到一瞬间内完成而无法捕捉到状态的变化,这时 show engine innodb status 的结果将是各种LSN相等。

恢复

mysql的恢复策略是:

1.恢复时,先根据redo重做所有事务,包括未提交的事务

2.再根据undo回滚未提交的事务。

通过这种策略,保证了事务的原子性、一致性和持久性。

另外,引入了checkpoint机制,在恢复的时候,只需要从checkpoint的位置往后恢复即可。

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-06-26
本文作者:shidawuhen
本文来自:“掘金”,了解相关信息可以关注“掘金”

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章