文章目录
- 一、事务的ACID特性
- 二、数据库原理例题与 ACID 特性判断
- 三、拓展(undolog 与 redolog)
一、事务的ACID特性
综述:
- 原子性(Atomicity):事务是不可分割的最小操作单元,要么全部成功,要么全部失败。
- 一致性(Consistency):事务完成时,必须使所有的数据都保持一致状态。
- 隔离性(Isolation):数据库系统提供的隔离机制,保证事务在不受外部并发操作影响的独立环境下运行。
- 持久性(Durability):事务一旦提交或回滚,它对数据库中的数据的改变就是永久的。
-
原子性(Atomicity):
- 通俗类比: 就像你去ATM取钱。整个取钱操作(输入密码、选择金额、出钞、打印凭条)是一个原子操作。如果中间任何一步失败了(比如机器故障没出钞),那么整个操作就会被撤销,你的账户余额不会改变,就像你没取过钱一样。如果全部成功,你的账户余额才会减少,你拿到钱。
- 核心思想: 事务中的所有操作要么作为一个整体被执行成功,要么作为一个整体被回滚(撤销)。没有中间状态。
- 实现方式: 通常通过日志(如Undo Log)来实现。如果事务执行过程中发生错误,系统会根据日志回滚到事务开始前的状态。
-
一致性(Consistency):
- 通俗类比: 想象一个银行账户的总金额。在任何一个事务执行前后,所有账户的总金额应该保持不变(假设没有外部资金流入流出)。如果你从账户A转账100元到账户B,事务开始前,A+B的总金额是X。事务结束后,A减少100,B增加100,A+B的总金额仍然是X。这就是一致性。
- 核心思想: 事务必须使数据库从一个一致性状态转换到另一个一致性状态。一致性状态是指数据库满足所有的预定义规则和约束(例如,主键唯一、外键引用有效、余额不能为负等)。
- 实现方式: 依赖于原子性、隔离性、持久性,以及数据库本身的约束(如外键约束、唯一性约束、Check约束等)。程序员编写的业务逻辑也需要保证一致性。
-
隔离性(Isolation):
- 通俗类比: 想象你在图书馆看书,旁边有人也在看书。隔离性就像是你们之间有隔板,互不影响。你在翻页、做笔记,旁边的人也在做自己的事情,你们不会看到对方操作的中间状态,也不会互相干扰。
- 核心思想: 并发执行的事务之间互不干扰,每个事务都感觉自己是系统中唯一正在运行的事务。一个事务的中间结果对其他事务是不可见的。
- 实现方式: 数据库提供了多种隔离级别(如读未提交、读已提交、可重复读、串行化),通过锁机制、多版本并发控制(MVCC)等技术来实现不同程度的隔离。
-
持久性(Durability):
- 通俗类比: 你在电脑上写了一篇文档,点击了“保存”。即使电脑突然断电,当你重新开机时,你保存的文档依然存在。这就是持久性。
- 核心思想: 一旦事务提交成功,它对数据库数据的改变就是永久性的,即使系统发生故障(如断电、崩溃)也不会丢失。
- 实现方式: 通常通过将事务的修改写入到日志文件(如Redo Log)中来实现。即使数据还没有完全写入磁盘,只要相关的日志已经写入磁盘,系统恢复时就可以通过日志来重做(Redo)这些操作,恢复到事务提交后的状态。
二、数据库原理例题与 ACID 特性判断
下面我们通过一些例子来帮助你判断和理解这些特性。请判断每个例子主要体现了事务的哪种 ACID 特性。
例题 1:
你在一个电商网站上下单购买商品。这个操作包括:
- 从库存表中减少商品数量。
- 在订单表中插入一条新的订单记录。
- 从用户余额中扣除支付金额。
如果在执行过程中,扣除用户余额时发生了网络错误导致失败,整个下单操作被取消,库存数量和订单记录都没有发生改变。
请问:这个例子主要体现了事务的哪种特性?为什么?
答案与解析:
这个例子主要体现了事务的 原子性(Atomicity)。
原因:整个下单过程被视为一个不可分割的单元。当其中一个步骤(扣除用户余额)失败时,整个事务被回滚,之前已经执行的步骤(减少库存、插入订单)也被撤销,系统回到了事务开始前的状态。这符合原子性“要么全部成功,要么全部失败”的定义。
例题 2:
一个银行系统中有规定:所有账户的总金额必须大于等于零。
现在有两个账户 A 和 B,A 有 1000元,B 有 500元。
一个事务从 A 账户转账 200元到 B 账户。
事务执行完成后,A 账户变为 800元,B 账户变为 700元。
此时,所有账户的总金额(800 + 700 = 1500)仍然大于等于零,符合银行系统的规定。
请问:这个例子主要体现了事务的哪种特性?为什么?
这个例子主要体现了事务的 一致性(Consistency)。
原因:事务执行前后,数据库从一个一致性状态(所有账户总金额 >= 0)转换到了另一个一致性状态(所有账户总金额 >= 0)。尽管账户A和B的金额发生了变化,但它们的变化是相互抵消的,维护了数据库的业务规则和约束。
例题 3:
两个用户同时尝试购买同一件限量商品。
用户 A 的事务开始执行,查询到商品库存为 1。
用户 B 的事务几乎同时开始执行,也查询到商品库存为 1。
用户 A 的事务执行扣减库存操作,库存变为 0,然后提交。
用户 B 的事务也执行扣减库存操作,如果隔离性不好,它可能会在用户 A 提交前就看到库存为 1,然后也尝试扣减,导致库存变为 -1(超卖)。
但由于数据库的隔离机制,用户 B 在尝试扣减库存时,会发现库存已经被用户 A 修改为 0,从而导致用户 B 的扣减库存操作失败(或者被阻塞等待)。最终只有一个用户购买成功,库存变为 0。
请问:这个例子主要体现了事务的哪种特性?为什么?
这个例子主要体现了事务的 隔离性(Isolation)。
原因:在并发环境下,多个事务同时访问和修改相同的数据。隔离性确保了每个事务的执行不受其他并发事务的干扰。在这个例子中,良好的隔离性防止了“超卖”问题的发生,保证了用户 B 在用户 A 提交后能够看到最新的库存状态,避免了基于过期数据进行操作。
例题 4:
你成功地完成了一笔订单支付,事务提交成功。
即使紧接着数据库服务器发生了突然的断电,当你重新启动数据库后,查询订单列表,仍然能够找到刚才支付成功的订单记录,并且你的账户余额也确实被扣除了。
请问:这个例子主要体现了事务的哪种特性?为什么?
这个例子主要体现了事务的 持久性(Durability)。
原因:一旦事务提交成功,其对数据库的修改就被认为是永久的,即使系统发生故障,这些修改也不会丢失。数据库通过将提交的事务信息写入日志等方式来保证数据不会因为意外情况而丢失。
三、拓展(undolog 与 redolog)
Q1: 详细解释一下,数据库是如何实现 原子性 的吗?特别是当事务执行到一半发生崩溃时,数据库如何确保之前已经执行的操作被撤销?
A: 原子性是通过日志来实现的。数据库会记录事务的每一步操作。如果事务失败了,就可以根据日志把已经执行的操作撤销掉,回到事务开始前的状态。
Q2: “日志”具体是指哪种日志?撤销操作的原理是什么?
A: 数据库主要依赖 Undo Log 来实现原子性。Undo Log 记录了数据修改前的值。如果事务需要回滚,系统会读取 Undo Log,根据日志中记录的旧值将数据恢复到修改前的状态。
Q3: 那么,Undo Log
是在事务提交后才清除吗?如果在事务提交前数据库崩溃了,Undo Log
起什么作用?
A: Undo Log 不是在事务提交后立即清除,而是会保留一段时间,直到相关的事务彻底完成并且不再需要回滚。如果在事务提交前数据库崩溃了,当数据库重启进行恢复时,会检查未完成的事务,并利用 Undo Log 将这些未完成事务已经进行的修改回滚,确保这些事务是“不存在”的,这正是原子性的体现。
Q4: 你提到了 Undo Log
用于回滚。那么,持久性 是如何保证的呢?它依赖哪种日志?如果事务提交后,数据还没完全写入磁盘,但日志已经写入了,然后数据库崩溃了,数据还能恢复吗?
A: 持久性主要依赖 Redo Log。Redo Log 记录了数据修改后的值。当事务提交时,数据库会确保 Redo Log 相关的记录已经写入磁盘。即使数据页本身还没来得及写入磁盘,只要 Redo Log 已经持久化了,系统恢复时就可以通过读取 Redo Log 来重做(Redo)这些操作,将数据恢复到事务提交后的状态。
Q5: 所以,Redo Log
和 Undo Log
在保证ACID特性中扮演了不同的角色。你能总结一下它们各自的主要作用吗?
A: 好的。简单来说,Undo Log 主要用于保证 原子性,它记录了数据修改前的状态,用于回滚事务。Redo Log 主要用于保证 持久性,它记录了数据修改后的状态,用于在系统崩溃恢复时重做已提交的事务。它们是数据库实现事务ACID特性的重要底层机制。
Q6: 你提到了 隔离性 有不同的级别,比如读未提交、读已提交、可重复读、串行化。你能简单解释一下“读未提交”隔离级别可能带来的问题吗?
A: 读未提交(Read Uncommitted)是隔离级别最低的。它允许一个事务读取另一个未提交事务的修改。这可能导致 脏读(Dirty Read) 问题。例如,事务A修改了一行数据但还没有提交,事务B读取了这行被修改但未提交的数据。如果事务A随后回滚了这次修改,那么事务B读取到的数据就是无效的、不存在的数据,这就是脏读。