type
status
date
slug
summary
tags
category
icon
password
Property
Sep 25, 2024 09:36 AM
此页面会持续保持更新
事务的定义
- 事务是多个数据库操作组合成的一个不可分割的、同时成功或失败的工作单元
事务的特性（ACID）
- 原子性（atomicity）：不可分割，事务单元全部成功或者全部失败
- 一致性（consistency）：正确一致，一个正确（一致）的状态转移到另一个正确 的状态
- 隔离性（isolation）：互不干扰，多个事务在并发执行的过程中所得到的结果，和 串行执行得到的结果是一致
- 持久性（durability）：永久保持，执行结果不会丢失
调度
- 为了更好地解释并发控制过程中，数据库对事务的处理流程，首先引入一个概念：调度
- 调度为事务的并发过程中，决定事务中每个操作的执行顺序
串行调度(serial schedule)
事务串行执行
调度定义下的并发控制
- 给定一个并发调度S ，存在一个串行调度S’， 在任何数据库状态下，按照调度S 和调度S’执行后所产生的结果都是相同的 。
- 此时调度S 被称之为可串行化调度（serializable schedule）
可串行化调度的数量十分巨大，且难以校验，数据库中一般通过找到可串行化调度的子集（充分条件）即找到能够提前确认是可串行调度的并发调度，进而提升调度效率。
视图可串行化（View Serializability）
视图可串行化是指一个并发执行的事务调度，如果其结果与某个串行调度执行的结果相同，那么这个并发调度是视图可串行化的。视图可串行化的核心在于事务的读写操作对数据库状态的影响，它不依赖于事务的具体执行顺序，而是依赖于事务的读写集合。
- 定义：如果存在一个串行调度，使得每个事务的读写集合与并发调度中的读写集合相同，则该并发调度是视图可串行化的。
- 特点：
- 不需要关心事务操作的先后顺序，只关心操作对数据的影响。
- 需要分析事务的读写操作，确定它们是否可以产生相同的结果。
冲突可串行化（Conflict Serializability）
冲突可串行化是指在事务的执行过程中，通过分析事务之间的冲突操作（读写冲突和写写冲突），来判断一个并发调度是否可以转换为一个等价的串行调度。
- 定义：如果可以通过交换非冲突操作将一个并发调度转换为串行调度，则该并发调度是冲突可串行化的。
- 特点：
- 依赖于事务操作的先后顺序，特别是冲突操作的顺序。
- 通常使用优先图（Precedence Graph）或者串行化图（Serializability Graph）来检测冲突可串行化。
视图可串行化与冲突可串行化的关系
- 包含关系：所有冲突可串行化的调度都是视图可串行化的，但反之不成立。也就是说，冲突可串行化是视图可串行化的一个子集。
- 判定方法：冲突可串行化通常更容易检测，因为它只关注事务间的冲突操作。而视图可串行化的判定则更为复杂，需要对事务的读写集合进行分析。
事务的隔离级别
- 读未提交（read uncommitted）
- 读已提交（read committed）
- 可重复读（repeatable read）
- 可串行化（serializable）
可重复读（Repeatable Read）
可重复读是指在一个事务内，多次读取同一数据集合的结果是一致的，即使有其他事务同时修改这些数据，也不会影响当前事务的读取结果。这是因为在可重复读隔离级别下，事务会对它读取的数据加锁，直到事务结束。
幻读（Phantom Read）
幻读是指在同一个事务中，当事务第一次读取某个范围的数据后，如果另一个事务在这个范围内插入了新的数据，那么当前事务在后续的查询中会读到这些新插入的数据，就像“幻影”一样突然出现。
可重复读和幻读区别
- 数据变化类型：
- 可重复读：关注的是数据行的变化。在同一个事务中，即使其他事务更新了某些行，当前事务也能看到一致的数据。
- 幻读：关注的是数据行的增加或减少。在同一个事务中，即使其他事务插入了新行或删除了现有行，当前事务在后续的查询中可能会看到这些变化。
- 隔离级别：
- 可重复读：通常在可重复读隔离级别下讨论，这个级别旨在防止更新丢失和脏读。
- 幻读：在可重复读隔离级别下仍然可能出现，但在串行化（Serializable）隔离级别下可以完全避免。
- 锁的范围：
- 可重复读：通常通过对读取的数据行加共享锁来实现，这些锁可以防止其他事务对这些行的修改。
- 幻读：即使在可重复读隔离级别下对读取的数据行加了共享锁，也无法防止其他事务插入新行，因为这些新行在加锁之前并不存在。
- 解决方法：
- 可重复读：通过行级锁或多版本并发控制（MVCC）等技术来实现。
- 幻读：在串行化隔离级别下，通常需要范围锁（例如间隙锁）来防止幻读。
事务原子性和持久性的实现
原子性
- 事务运行期间不刷盘，故障系统重启后自动保证原子性；
- 事务运行期间刷盘，故障系统重启需回滚该事务
持久性
- 事务完成（commit、abort）时刷盘，故障系统重启后自动保证持久性；
- 事务完成时不刷盘，故障系统重启后需重做该事务
数据库故障类别
事务故障：数据库事务因为资源冲突或者死锁等原因导致执行失败
系统崩溃：数据库自身或操作系统的故障导致数据库进程意外退出
磁盘故障：数据因为磁盘（其他非易失性存储）损坏导致无法被读取
自然灾害：自然灾害对数据库系统所在的环境造成了彻底性破坏
数据库恢复机制架构
无故障事务回滚（例如账户小于0）
- 影响原子性，撤销该事务已做操作
故障失误回滚（例如死锁杀死事务）
- 影响原子性，撤销该事务已做操作
系统故障（例如重启）：内存数据丢失，影响原子性和持久性
- 原子性：撤销未结束（不带Commit、Abort标记）的事务
- 持久性：重做已经结束（带Commit或Abort标记）的事务
系统崩溃不能重启：不能提供服务，影响持久性
- 一主多备：主备之间通过日志保持一致性，发生故障后切换到其他系统
磁盘故障：磁盘数据丢失，影响持久性
- 磁盘数据多副本；数据备份机制：创建数据备份、日志备份
自然灾害：系统宕机不能重启，影响持久性
- 异地多机容灾：多机实时传输日志保证一致性，发生故障后切换到其他系统
系统崩溃恢复
系统崩溃诱因
- 数据库进程被操作系统中止
- 管理员错误操作
- 软件故障、死锁
特点
- 出现频率较高
- 缓冲区数据丢失、磁盘数据不完整
影响
- 原子性
- 持久性
系统崩溃下的事务
已完成的事务
- 已提交的事务（Commit标记）：它们对数据库的修改可能没有写回磁盘，缓冲区数据丢 失后这些修改无法找回。事务的持久性受到了影响，需要重做这些事务。
- 已中止的事务（Abort标记） ：系统对这些事务的撤销可能没有写回磁盘，因此在重启之后这些撤销内容会丢失。事务的持久性受到了影响，需要重做这些事务。
未完成的事务（只有Start，没有Commit、Abort标记）
- 它们可能已经对数据库造成了修改，但是没有被系统提交，重启之后的数据库也没有撤销这些修改。事务的原子性受到了影响，需要回滚这些事务
崩溃恢复策略设计
原子性保证
- 选择①：NO-STEAL（非窃取）未结束事务不能将脏页写入磁盘，不存在原子性问题
- 选择②：STEAL（窃取）未结束事务能将脏页写入磁盘，影响原子性，需要回滚
持久性保证
- 选择①：Force（强制）已完成事务强制将脏页写入磁盘，不存在持久性问题
- 选择②：No-Force（非强制）已完成事务不强制将脏页写入磁盘，影响持久性，需要重做
保证持久性和原子性的方案选择
- 作者:GJJ
- 链接:https://blog.gaojj.cn/article/blog-103
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。