介绍事务
对事务进行控制
事务的特性：ACID
怎么实现事务的 ACID 特性
介绍 Spring 事务
介绍 Redis 的事务
介绍消息引擎系统的事务
介绍分布式事务
我的疑问
参考资料

介绍事务

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

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

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

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