介绍事务

技术是为了解决问题而生的,通过事务我们可以解决以下问题:

  • 多个操作不是一个整体操作,出现了部分执行成功的情况,导致数据的状态不一致问题(原子性)
  • 一组操作只有部分完成,没有全部完成,但是此时可以访问到数据的不一致状态问题(可见性问题,隔离性)
  • 两组操作并发执行,导致的并发问题
  • ……

事务存在的意义:保证系统中的数据是正确的,不同数据间不会产生矛盾,也就是保证数据状态的一致性。


事务是什么(事务的概念):事务是一个或多个操作的组合操作,并且事务对这个组合操作提供一个保证,如果这个组合操作执行之前的数据是一致的(即正确的),那么执行组合操作之后的数据也应该是一致的。不论这个组合操作执行的过程中,发生了系统故障,还是在这个组合操作执行的过程中,是否与其他事务一起执行。(这也对应了上面提到的事务要解决的问题)
即使没有事务支持, 或许上层应用依然可以工作, 然而在没有原子性保证时, 错误处理就会异常复杂, 而缺乏隔离性则容易出现并发性方面的各种奇怪问题。
如果我们期望多个操作同时成功或者失败,并且期望多组操作之间相互隔离(不相互影响),那么就需要通过一个事务来执行。
Oracle 是支持事务的。而 MySQL 中只有 InnoDB 存储引擎支持事务,MyISAM、Memory、Merge 等存储引擎都不支持事务。

对事务进行控制

事务
14丨什么是事务处理,如何使用COMMIT和ROLLBACK进行操作?
使用事务有两种方式,分别为:隐式事务和显式事务。

隐式事务

隐式事务又称自动提交事务,顾名思义就是当执行完一条 SQL 语句后,会自动 commit 提交。
MySQL 默认使用的就是隐式事务。

显式事务

如果我们想关闭自动提交,可以使用下边的两种方法之一:

  • 显式的的使用 start transaction 或者 begin 语句开启一个事务。这样,在本次事务提交或者回滚之前会暂时关闭自动提交功能。
  • 把系统变量 autocommit 的值设置为 off 或者 0:set autocommit = off。这样,本次会话将关闭自动提交功能。不论是否显式的开启一个事务,每次执行事务都需要使用 commit 进行提交让事务生效,使用 rollback 对事务进行回滚。

    需要注意的是:设置 autocommit 的值,只针对当前会话有效。

autocommit 参数的取值有 2 种可能:

  • autocommit = 0:取消自动提交功能
  • autocommit = 1:使用自动提交功能(默认值)

start transaction 比 begin 语句强大的一点是:可以在 start transaction 语句后面跟随几个修饰符,用来设置事务的访问模式,修饰符如下所示:

  • read only:标识当前事务是一个只读事务。即该事务内的操作只能读取数据,而不能修改数据。
  • read write:标识当前事务是一个读写事务。即该事务内的操作既可以读取数据,也可以修改数据。
  • with consistent snapshot:启动一致性读。即执行该命令后立即生成 ReadView,而不用等到第一条 select 语句执行。

如果我们想在 start transaction 后面跟随多个修饰符的话,使用逗号将修饰符分开即可,
如果不显式的指定事务的访问模式,那么该事务的访问模式默认为:读写模式。

保存点 savepoint

可以用 savepoint 保存点名称; 语句创建保存点,方便后续回滚到指定保存点。
保存点就是在事务对应的数据库语句中打几个点,我们在调用 rollback 语句时,可以回滚到指定的保存点,保留部分操作而非回滚到事务执行之前的状态。
当我们想回滚到指定的保存点时,可以使用这个语句:rollback [work] to [savepoint] 保存点名称;(单词 work 和 savepoint 可有可无)。
如果 rollback 语句后没有跟随保存点名称的话,会直接回滚到事务执行之前的状态。
如果我们想删除某个保存点,可以使用这个语句:release savepoint 保存点名称;

completion_type 参数

MySQL 中 completion_type 参数的取值有 3 种可能:

  • completion=0(no_chain),这种情况下,当我们执行 commit 的时候会提交事务,在执行下一个事务时,还是需要我们使用 start transaction 或者 begin 来开启事务。(参数的默认值)
  • completion=1(chain),这种情况下,当我们提交事务时,相当于执行了 commit and chain,也就是开启一个链式事务;即当我们提交事务之后,会开启一个相同隔离级别的事务。
  • completion=2(release),这种情况下,当我们提交事务时,相当于执行了 commit and release;即当我们事务之后,会自动与服务器断开连接。

    事务的特性:ACID

    14丨什么是事务处理,如何使用COMMIT和ROLLBACK进行操作?
    事务的特性分别是:原子性 (Atomicity)、一致性 (Consistency)、隔离性 (Isolation)、持久性 (Durability)。
    下面我们分别介绍这四个特性。

一致性:一个事务能够正确地将数据从一个一致性的状态,转换到另一个一致性的状态。
数据的一致性状态是指数据满足我们事先定义好的约束规则。也就是在事务执行的过程中,不论出现什么问题(比如停电、宕机),最终的执行结果都是满足我们事先定义好的约束规则的。
数据的一致性就是正确性。


原子性:一个事务中包含的所有操作,要么全部执行,要么一个都不执行,即 all-or nothing。
事务在执行过程中出现故障(宕机、断电、进程崩溃、某种完整性约束被违反),导致操作不能全部执行时,事务会被回滚 (Rollback) 到事务开始前的状态,就像这个事务从来没有执行过一样。


隔离性:如果多个事务并发执行,事务之间不应该出现相互影响的情况,它其实就是数据库的并发访问控制。
数据库试图通过事务隔离来对应用开发者隐藏,事务并发时可能出现的各种异常情况。
在实践中,由于考虑到性能的问题,会在高性能与正确性之间做一个权衡。使用者可以根据自己的业务场景,选择一个合适的隔离级别。


持久性:如果一个事务已经提交成功,那么不论出现什么问题(比如停电、宕机、存储介质发生故障、数据库崩溃),事务所写入的任何数据都不会丢失。

怎么实现事务的 ACID 特性

怎么实现一致性

22|事务(一):一致性,事务的集大成者
事务一致性的实现需要运用事务的原子性、隔离性和持久性。并且还要考虑事务执行的最终结果,是否满足我们事先定义好的约束规则,这就需要数据库层提供的约束检测,并且在应用层开发中做好相关的约束检测,如果检测发现事务的执行结果不满足我们事先定义好的约束规则,那么就需要将事务回滚,使数据处于之前的一致性状态。
也就是说,数据库本身只能为我们保证一部分一致性需求,更多的一致性需求需要程序员在应用层写业务代码自己保证。


:::info 举例说明 ::: 下面我们举一个【账户 A 向 账户 B 转账】的例子来说明事务一致性的实现:
在账户 A 向 账户 B 转账时,转账前后,我们定义账户 A 和 账户 B 必须满足以下的约束规则:

  • 账户的余额必须大于等于 0(字段取值范围的有效性可以用 check 约束来检测)
  • 转账前后,账户 A 和账户 B 的总余额必须相同(这个约束需要运用事务的原子性、隔离性、持久性来保证)

转账操作执行完成后,提交事务前,我们还需要检测此时的数据是否满足我们定义好的约束规则:

  • 如果不满足的话,说明此时的数据不是处于一致性的状态,那么就回滚事务,使数据处于之前的一致性状态。
  • 如果满足的话,说明此时的数据处于一致性的状态,可以提交事务。

:::info 数据库层提供的约束检测 ::: 对键进行约束

  • 主键约束:主键可以保证 unique + not null
  • 外键约束:外键保证了表与表之间引用的完整性

除了对键进行约束外,还有字段约束

  • 唯一性约束:用来检测字段在表中的数值是否唯一的(unique 索引)
  • not null 约束:用来检测字段的值是否为空
  • check 约束:用来检测字段取值范围的有效性(MySQL 仅支持 check 语法,但实际上并不起约束作用)

    怎么实现原子性

    23|事务(二):原子性,对应用层提供的完美抽象
    事务的原子性只关注整体的不可分割性,一个事务所有的操作,要么全部执行,要么一个都不执行,即 all-or nothing。
    那么如何实现事务的原子性呢?从不可分割性的角度来思考,实现一个事务需要解决两个维度上的操作分割:

  • 第一个维度是单节点上运行的事务,即单节点上操作的不可分割性(也就是一个节点上的操作,要么全部执行,要么一个都不执行)。

  • 第二个维度是多节点上运行的事务,即多节点之间的操作的不可分割性(也就是多个节点的操作,要么全部节点都执行,要么一个节点都不执行)。

对于本地事务来说,只需要实现单节点上操作的不可分割性即可。
而对于分布式事务来说,不仅要实现单节点上操作的不可分割性,还要实现多节点之间的操作的不可分割性。

对于本地事务来说

本地事务实现原子性,一般是在存储引擎上,使用“Write-Ahead Log”日志方案实现本地事务的原子性、持久性。具体实现思路看下面的文档。
日志:Redo Log 和 Undo Log

对于分布式事务来说

分布式事务实现原子性,不仅要实现单节点上操作的不可分割性,还要实现多节点之间的操作的不可分割性。
对于单节点上操作的不可分割性,可以通过“Write-Ahead Log”日志方案实现。
现在我们只需要保证,多节点之间的操作的不可分割性,即多个节点的操作要么全部节点都执行,要么一个节点都不执行。一个常见的思路是通过两阶段提交( 2PC )来解决。
具体的实现思路看下面的文档。
两阶段提交协议 2PC

怎么实现隔离性

实现隔离性:锁 & MVCC 机制

怎么保障持久性

实现持久性:Redo Log 和 Binlog

介绍 Spring 事务

Spring 事务

介绍 Redis 的事务

Redis 的事务机制

介绍 消息引擎系统 的事务

介绍分布式事务

分布式事务

我的疑问

completion_type 参数的作用是什么,什么场景下会用到不同的 completion_type

参考资料

14丨什么是事务处理,如何使用COMMIT和ROLLBACK进行操作?
主要讲事务的特性、对事务进行控制
事务
分布式事务
22|事务(一):一致性,事务的集大成者
23|事务(二):原子性,对应用层提供的完美抽象

以下文章还没看。

以下的文章也是和事务相关的文章,但是上面的文章内容未参考这部分。
15丨初识事务隔离:隔离的级别有哪些,它们都解决了哪些异常问题?
第36讲 | 谈谈MySQL支持的事务隔离级别,以及悲观锁和乐观锁的原理和应用场景?