网站建设公司正规吗,学做网页设计,video.js wordpress,武钢建工集团建设公司网站1 什么是数据库的事务#xff1f;
1.1 事务的典型场景
在项目里面#xff0c;什么地方会开启事务#xff0c;或者配置了事务#xff1f;无论是在方法上加注解#xff0c;还 是配置切面。
tx:advice idtxAdvice transaction-managertransactionMa…1 什么是数据库的事务
1.1 事务的典型场景
在项目里面什么地方会开启事务或者配置了事务无论是在方法上加注解还 是配置切面。
tx:advice idtxAdvice transaction-managertransactionManager
tx:attributes
tx:method namesave* rollback-forThrowable /
tx:method nameadd* rollback-forThrowable /
tx:method namesend* rollback-forThrowable /
tx:method nameinsert* rollback-forThrowable /
/tx:attributes
/tx:advice比如下单会操作订单表资金表物流表等等这个时候我们需要让这些操作都在一个事务里面完成。当一个业务流程涉及多个表的操作的时候我们希望它们要么是全部成功的要么都不成功这个时候我们会启用事务。 在金融的系统里面事务配置是很常见的比如行内转账的这种操作如果我们把它简单地理解为一个账户的余额增加另一个账户的余额减少的情况当然实际上要比这复杂那么这两个动作一定是同时成功或者同时失败的否则就会造成银行的会计科目不平衡。
1.2 事务的定义
什么是事务 维基百科的定义事务是数据库管理系统DBMS执行过程中的一个逻辑单位由一个有限的数据库操作序列构成。 这里面有两个关键点第一个它是数据库最小的工作单元是不可以再分的。第二个它可能包含了一个或者一系列的 DML 语句包括 insert delete update。单条 DDLcreate drop和 DCLgrant revoke也会有事务。
1.3 哪些存储引擎支持事务
在我们第一天的课里面说到了InnoDB 支持事务这个也是它成为默认的存储引擎的一个重要原因 https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html 另一个是 NDB
1.4 事务的四大特性
事务的四大特性ACID。 第一个原子性Atomicity也就是我们刚才说的不可再分也就意味着我们对数据库的一系列的操作要么都是成功要么都是失败不可能出现部分成功或者部分失败的情况。以转账的场景为例一个账户的余额减少对应一个账户的增加这两个一定是同时成功或者同时失败的。 全部成功比较简单问题是如果前面一个操作已经成功了后面的操作失败了怎么让它全部失败呢这个时候我们必须要回滚。 原子性在 InnoDB 里面是通过 undo log 来实现的它记录了数据修改之前的值逻辑日志一旦发生异常就可以用 undo log 来实现回滚操作。 第二个一致性consistent指的是数据库的完整性约束没有被破坏事务执行的前后都是合法的数据状态。比如主键必须是唯一的字段长度符合要求。 除了数据库自身的完整性约束还有一个是用户自定义的完整性。 比如说转账的这个场景A 账户余额减少 1000B 账户余额只增加了 500这个时候因为两个操作都成功了按照我们对原子性的定义它是满足原子性的 但是它没有满足一致性因为它导致了会计科目的不平衡。 还有一种情况A 账户余额为 0如果这个时候转账成功了A 账户的余额会变成-1000虽然它满足了原子性的但是我们知道借记卡的余额是不能够小于 0 的所以也违反了一致性。用户自定义的完整性通常要在代码中控制。 第三个隔离性Isolation我们有了事务的定义以后在数据库里面会有很多的事务同时去操作我们的同一张表或者同一行数据必然会产生一些并发或者干扰的操作那么我们对隔离性的定义就是这些很多个的事务对表或者行的并发操作应该是透明的互相不干扰的。通过这种方式我们最终也是保证业务数据的一致性。 最后一个叫做持久性Durable事务的持久性是什么意思呢我们对数据库的任意的操作增删改只要事务提交成功那么结果就是永久性的不可能因为我们系统宕机或者重启了数据库的服务器它又恢复到原来的状态了。这个就是事务的持久性。 持久性怎么实现呢数据库崩溃恢复crash-safe是通过什么实现的 持久性是通过 redo log 和 double write 双写缓冲来实现的我们操作数据的时候会先写到内存的 buffer pool 里面同时记录 redo log如果在刷盘之前出现异常在重启后就可以读取 redo log 的内容写入到磁盘保证数据的持久性。 当然恢复成功的前提是数据页本身没有被破坏是完整的这个通过双写缓冲double write保证。 原子性隔离性持久性最后都是为了实现一致性。
1.5 数据库什么时候会出现事务
无论是我们在 Navicat 的这种工具里面去操作还是在我们的 Java 代码里面通过API 去操作还是加上Transactional 的注解或者 AOP 配置其实最终都是发送一个指令到数据库去执行Java 的 JDBC 只不过是把这些命令封装起来了。 我们先来看一下我们的操作环境。版本5.7存储引擎InnnoDB事务隔离级别RR。
select version();
show variables like %engine%;
show global variables like tx_isolation;执行这样一条更新语句的时候它有事务吗
update student set sname 猫老公 111 where id1;实际上它自动开启了一个事务并且提交了所以最终写入了磁盘。 这个是开启事务的第一种方式自动开启和自动提交。 InnoDB 里面有一个 autocommit 的参数分成两个级别 session 级别和 global级别。
show variables like autocommit;它的默认值是 ON。autocommit 这个参数是什么意思呢是否自动提交。如果它的值是 true/on 的话我们在操作数据的时候会自动开启一个事务和自动提交事务。 否则如果我们把 autocommit 设置成 false/off那么数据库的事务就需要我们手动地去开启和手动地去结束。 手动开启事务也有几种方式一种是用 begin一种是用 start transaction。 那么怎么结束一个事务呢我们结束也有两种方式第一种就是提交一个事务commit还有一种就是 rollback回滚的时候事务也会结束。还有一种情况客户端的连接断开的时候事务也会结束。 后面我们会讲到当我们结束一个事务的时候事务持有的锁就会被释放无论是 提交还是回滚。 我们用 begin 手工开启一个事务执行第二个 update但是数据没有写入磁盘因为事务还没有提交这个时候 commit 一下再刷新一下OK写入了。 这个就是我们开启和结束事务的两种方式。
1.6 事务并发会带来什么问题
当很多事务并发地去操作数据库的表或者行的时候如果没有我们刚才讲的事务的Isolation 隔离性的时候会带来哪些问题呢 我们有两个事务一个是 Transaction A一个是 Transaction B在第一个事务里面它首先通过一个 where id1 的条件查询一条数据返回 nameAdaage16 的这条数据。然后第二个事务它同样地是去操作 id1 的这行数据它通过一个 update的语句把这行 id1 的数据的 age 改成了 18但是注意它没有提交。 这个时候在第一个事务里面它再次去执行相同的查询操作发现数据发生了变化获取到的数据 age 变成了 18。那么这种在一个事务里面由于其他的时候修改了数据并且没有提交而导致了前后两次读取数据不一致的情况这种事务并发的问题 我们把它定义成什么 这个叫做脏读。 如果在转账的案例里面我们第一个事务基于读取到的第二个事务未提交的余额进行了操作但是第二个事务进行了回滚这个时候就会导致数据不一致。 这种读取到其他事务未提交的数据的情况我们把它叫做脏读。 同样是两个事务第一个事务通过 id1 查询到了一条数据。然后在第二个事务里面执行了一个 update 操作这里大家注意一下执行了 update 以后它通过一个 commit提交了修改。然后第一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况就像这里age 到底是等于 16 还是 18那么这种事务并发带来的问题我们把它叫做什么 这种一个事务读取到了其他事务已提交的数据导致前后两次读取数据不一致的情况我们把它叫做不可重复读。 在第一个事务里面我们执行了一个范围查询这个时候满足条件的数据只有一条。 在第二个事务里面它插入了一行数据并且提交了。重点插入了一行数据。在第一个事务里面再去查询的时候它发现多了一行数据。这种情况我们把它叫做什么呢 一个事务前后两次读取数据数据不一致是由于其他事务插入数据造成的这种情况我们把它叫做幻读。 不可重复读和幻读的区别在那里呢 不可重复读是修改或者删除幻读是插入。 小结我们刚才讲了事务并发带来的三大问题现在来给大家总结一下。无论是脏读还是不可重复读还是幻读它们都是数据库的读一致性的问题都是在一个事务里面前后两次读取出现了不一致的情况。 读一致性的问题必须要由数据库提供一定的事务隔离机制来解决。就像我们去饭店吃饭基本的设施和卫生保证都是饭店提供的。那么我们使用数据库隔离性的问题也必须由数据库帮助我们来解决。
1.7 SQL92 标准
所以就有很多的数据库专家联合制定了一个标准也就是说建议数据库厂商都按照这个标准提供一定的事务隔离级别来解决事务并发的问题这个就是 SQL92 标准。 我们来看一下 SQL92 标准的官网。 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt 这里面有一张表格搜索_iso里面定义了四个隔离级别右边的 P1 P2 P3 就是代表事务并发的 3 个问题脏读不可重复读幻读。Possible 代表在这个隔离级别下这个问题有可能发生换句话说没有解决这个问题。Not Possible 就是解决了这个问题。 我们详细地分析一下这 4 个隔离级别是怎么定义的。 第一个隔离级别叫做Read Uncommitted未提交读一个事务可以读取到其他事务未提交的数据会出现脏读所以叫做 RU它没有解决任何的问题。 第二个隔离级别叫做Read Committed已提交读也就是一个事务只能读取到其他事务已提交的数据不能读取到其他事务未提交的数据它解决了脏读的问题但是会出现不可重复读的问题。 第三个隔离级别叫做Repeatable Read (可重复读)它解决了不可重复读的问题也就是在同一个事务里面多次读取同样的数据结果是一样的但是在这个级别下没有定义解决幻读的问题。 最后一个就是Serializable串行化在这个隔离级别里面所有的事务都是串行执行的也就是对数据的操作需要排队已经不存在事务的并发操作了所以它解决了所有的问题。 这个是 SQL92 的标准但是不同的数据库厂商或者存储引擎的实现有一定的差异比如 Oracle 里面就只有两种 RC已提交读和 Serializable串行化。那么 InnoDB的实现又是怎么样的呢
1.8 MySQL InnoDB 对隔离级别的支持
在 MySQL InnoDB 里面不需要使用串行化的隔离级别去解决所有问题。那我们来看一下 MySQL InnoDB 里面对数据库事务隔离级别的支持程度是什么样的。 InnoDB 支持的四个隔离级别和 SQL92 定义的基本一致隔离级别越高事务的并发度就越低。唯一的区别就在于InnoDB 在 RR 的级别就解决了幻读的问题。这个也是InnoDB 默认使用 RR 作为事务隔离级别的原因既保证了数据的一致性又支持较高的并发度。
1.9 两大实现方案
那么大家想一下如果要解决读一致性的问题保证一个事务中前后两次读取数据结果一致实现事务隔离应该怎么做我们有哪一些方法呢你的思路是什么样的呢总体上来说我们有两大类的方案。
1.9.1 LBCC
第一种我既然要保证前后两次读取数据一致那么我读取数据的时候锁定我要操作的数据不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制 LockBased Concurrency ControlLBCC。 如果仅仅是基于锁来实现事务隔离一个事务读取的时候不允许其他时候修改那就意味着不支持并发的读写操作而我们的大多数应用都是读多写少的这样会极大地影响操作数据的效率。
1.9.2 MVCC
所以我们还有另一种解决方案如果要让一个事务前后两次读取的数据保持一致那么我们可以在修改数据的时候给它建立一个备份或者叫快照后面再来读取这个快照就行了。这种方案我们叫做多版本的并发控制 Multi Version Concurrency ControlMVCC。 MVCC 的核心思想是 我可以查到在我这个事务开始之前已经存在的数据即使它在后面被修改或者删除了。在我这个事务之后新增的数据我是查不到的。 问题这个快照什么时候创建读取数据的时候怎么保证能读取到这个快照而不是最新的数据这个怎么实现呢 InnoDB 为每行记录都实现了两个隐藏字段 DB_TRX_ID6 字节插入或更新行的最后一个事务的事务 ID事务编号是自动递增的我们把它理解为创建版本号在数据新增或者修改为新数据的时候记录当前事务 ID。 DB_ROLL_PTR7 字节回滚指针我们把它理解为删除版本号数据被删除或记录为旧数据的时候记录当前事务 ID。 我们把这两个事务 ID 理解为版本号。 https://www.processon.com/view/link/5d29999ee4b07917e2e09298 MVCC 演示图 第一个事务初始化数据检查初始数据 此时的数据创建版本是当前事务 ID删除版本为空 第二个事务执行第 1 次查询读取到两条原始数据这个时候事务 ID 是 2 第三个事务插入数据
此时的数据多了一条 tom它的创建版本号是当前事务编号3 第二个事务执行第 2 次查询: MVCC 的查找规则只能查找创建时间小于等于当前事务 ID 的数据和删除时间大于当前事务 ID 的行或未删除。 也就是不能查到在我的事务开始之后插入的数据tom 的创建 ID 大于 2所以还是只能查到两条数据。 第四个事务删除数据删除了 id2 此时的数据jack 的删除版本被记录为当前事务 ID4其他数据不变 在第二个事务中执行第 3 次查询: 查找规则只能查找创建时间小于等于当前事务 ID 的数据和删除时间大于当前事务 ID 的行或未删除。 也就是在我事务开始之后删除的数据所以 jack 依然可以查出来。所以还是这两条数据。 第五个事务执行更新操作这个事务事务 ID 是 5 此时的数据更新数据的时候旧数据的删除版本被记录为当前事务 ID 5undo产生了一条新数据创建 ID 为当前事务 ID 5 查找规则只能查找创建时间小于等于当前事务 ID 的数据和删除时间大于当前事务 ID 的行或未删除。 因为更新后的数据 penyuyan 创建版本大于 2代表是在事务之后增加的查不出来。 而旧数据 qingshan 的删除版本大于 2代表是在事务之后删除的可以查出来。通过以上演示我们能看到通过版本号的控制无论其他事务是插入、修改、删除第一个事务查询到的数据都没有变化。 在 InnoDB 中MVCC 是通过 Undo log 实现的。 Oracle、Postgres 等等其他数据库都有 MVCC 的实现。 需要注意在 InnoDB 中MVCC 和锁是协同使用的这两种方案并不是互斥的。 第一大类解决方案是锁锁又是怎么实现读一致性的呢
