简单网上书店网站建设php,微盟商城小程序,户外媒体网站建设免费,个人网页需要什么内容文章目录 数据库事务事务特性(ACID)原子性(Atomicity)一致性(Consistency)隔离性(Isolation)持久性(Durability) 隔离级别Read Uncommitted(读未提交)Read Committed(读已提交)Repeatable Read(可重复读)Serializable(可串行化) Spring事务机制实现方式提交方式事务隔离级别事务… 文章目录 数据库事务事务特性(ACID)原子性(Atomicity)一致性(Consistency)隔离性(Isolation)持久性(Durability) 隔离级别Read Uncommitted(读未提交)Read Committed(读已提交)Repeatable Read(可重复读)Serializable(可串行化) Spring事务机制实现方式提交方式事务隔离级别事务传播行为事务回滚规则事务常用配置失效场景 数据库事务
什么叫事务?
事务是一系列对系统中数据进行访问与更新的操作组成的一个程序逻辑单元。即不可分割的许多基础数据库操作。
事务特性(ACID)
原子性(Atomicity)
原子性是指一个事务事务是最小的执行单位是一个不可分割的工作单元其中的操作要么都做要么都不做。如果事务中一个sql语句执行失败则已执行的语句也必须回滚数据库退回到事务前的状态。
实现原理
① 回滚日志undo log
InnoDB实现回滚靠的是undo log。当事务对数据库进行修改时InnoDB会生成对应的undo log。如果事务执行失败或调用了rollback导致事务需要回滚便可利用undo log中的信息将数据回滚到修改前。
对于每个insert回滚时会执行delete对于每个 delete回滚时会执行insert对于每个 update回滚时会执行一个相反的 update把数据改回去
一致性(Consistency)
一致性是指事务执行结束后数据库的完整性约束没有被破坏事务执行的前后都是合法的数据状态。
数据库的完整性约束包括但不限于实体完整性如行的主键存在且唯一、列完整性如字段的类型、大小、长度要符合要求、外键约束、用户自定义完整性如转账前后两个账户余额的和应该不变。假如A账户给B账户转10块钱不管成功与否A和B的总金额是不变的。
实现原理
一致性是事务追求的最终目标。前面提到的原子性、持久性和隔离性都是为了保证数据库状态的一致性。此外除了数据库层面的保障一致性的实现也需要应用层面进行保障。实现一致性的措施包括
① 保证原子性、持久性和隔离性。如果这些特性无法保证事务的一致性也无法保证
② 数据库本身提供保障。如不允许向整型列插入字符串值、字符串长度不能超过列的限制等
③ 应用层面进行保障。如转账操作只扣除转账者余额而未增加接收者余额
隔离性(Isolation)
**隔离性是指事务内部的操作与其它事务是隔离的并发执行的各个事务之间不能互相干扰。**严格的隔离性对应了事务隔离级别中的Serializable (可串行化)但实际应用中出于性能方面的考虑很少会使用可串行化。
实现原理
隔离性追求的是并发情形下事务之间互不干扰。主要分为两个方面
① 加锁机制保证隔离性(一个事务)写操作对(另一个事务)写操作的影响
事务在修改数据之前需要先获得相应的锁获得锁之后事务便可以修改数据该事务操作期间这部分数据是锁定的其它事务如果需要修改数据需要等待当前事务提交或回滚后释放锁。
② MVCC(多版本并发控制)保证隔离性(一个事务)写操作对(另一个事务)读操作的影响
MVCC全称Multi-Version Concurrency Control即多版本的并发控制协议。最大优点是读不加锁因此读写不冲突并发性能好。InnoDB的MVCC实现了多个版本的数据可共存主要基于以下技术及数据结构
隐藏列在Innodb引擎中每行数据都会有两个隐藏列实际是三个列 隐藏idid如果建表时没有显式指定则会生成这个隐藏id作为主键实际和mvcc没有关系创建版本号data_trx_id事务id用来标识最近对本行记录做修改的事务 id回滚指针data_roll_pointer指向undo log的指针 基于undo log版本链每条undo log也会指向更早版本的undo log从而形成一条版本链ReadView**通过隐藏列和版本链可以将数据恢复到指定版本但具体要恢复到哪个版本则需要根据ReadView来确定。**当进行查询操作时事务会生成一个ReadView是一个事务快照准确来说是当前时间点系统内活跃的事务列表也就是说系统内所有未提交的事务都会记录在这个Readview内事务就根据它来判断哪些数据是可见的哪些是不可见的。在每一条 SQL 开始的时候被创建有几个重要属性 trx_ids: 当前系统活跃(未提交)事务版本号集合low_limit_id: 创建当前 read view 时“当前系统最大事务版本号1”up_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号”creator_trx_id: 创建当前read view的事务版本号
MVCC查询流程
现在开始查询一个 select 过来了找到了一行数据。
data_trx_id up_limit_id说明数据在当前事务之前就存在了显示data_trx_id low_limit_id说明该数据是在当前read view 创建后才产生的数据不显示。不显示怎么办根据 data_roll_pointer 从 undo log 中找到历史版本找不到就空up_limit_id data_trx_id low_limit_id就要看隔离级别了
MVCC应用场景
在Mysql的InnoDB引擎中只有已提交读和可重复读这两种隔离级别的事务采用了MVCC机制
已提交读(READ COMMITTD)事务中的每次读操作都会生成一个新的ReadView也就是说如果这期间某个事务提交了那么它就会从ReadView中移除。这样确保事务每次读操作都能读到相对比较新的数据可重复读(REPEATABLE READ)事务只有在第一次进行读操作时才会生成一个ReadView后续的读操作都会重复使用这个ReadView。也就是说如果在此期间有其他事务提交了那么对于可重复读来说也是不可见的因为对它来说事务活跃状态在第一次进行读操作时就已经确定下来后面不会修改了
持久性(Durability)
持久性是指事务一旦提交它对数据库的改变就应该是永久性的即使数据库发生故障也不受影响。
实现原理
① redo log
当数据修改时除了修改Buffer Pool中的数据还会在redo log记录这次操作当事务提交时会调用fsync接口对redo log进行刷盘刷脏页。如果MySQL宕机重启时可以读取redo log中的数据对数据库进行恢复。redo log采用的是WALWrite-ahead logging预写式日志所有修改先写入日志再更新到Buffer Pool保证了数据不会因MySQL宕机而丢失从而满足了持久性要求。
为什么redo log写入磁盘比直接将Buffer Pool中修改数据写入磁盘刷脏快
刷脏是随机I/O因为每次修改的数据位置随机但写redo log是追加操作属于顺序I/O刷脏是以数据页Page为单位的MySQL默认页大小是16KB一个Page上一个小修改都要整页写入而redo log中只包含真正需要写入的部分无效I/O大大减少
隔离级别
事务并发问题
在事务的并发操作中不做隔离操作则可能会出现 脏读、不可重复读、幻读 问题 脏读指一个事务读取到了另一个未提交事务修改过的数据 事务A中读到了事务B中未提交的更新数据内容然后B回滚操作那么A读取到的数据是脏数据。 不可重复读同一个事务内前后多次读取读取到的数据内容不一致 事务A读到事务B已经提交后的数据即事务A多次读取同一数据时返回结果不一致。 幻读指一个事务先根据某些搜索条件查询出一些记录在该事务未提交时另一个事务写入了一些符合那些搜索条件的记录如insert、delete、update再次查询出的结果则出现不一致 事物A执行select后事物B增或删了一条数据事务A再执行同一条SQL后发现多或少了一条数据。 第一类丢失更新 A事务撤销事务时覆盖了B事务提交的事务现代关系型数据库中已经不会发生 第二类丢失更新 A事务提交事务时覆盖了B事务提交的事务是不可重复读的特殊情况
小结不可重复读的和幻读很容易混淆不可重复读侧重于修改幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行解决幻读需要锁表。查看 mysql 事务隔离级别show variables like tx_iso%;。
InnoDB存储引擎下的四种隔离级别发生问题的可能性如下
隔离级别第一类丢失更新第二类丢失更新脏读不可重复读幻读Read Uncommitted(读未提交)不可能可能可能可能可能Read Committed(读已提交)不可能可能不可能可能可能Repeatable Read(可重复读)不可能不可能不可能不可能可能Serializable(串行化)不可能不可能不可能不可能不可能
Read Uncommitted(读未提交)
只限制了两个数据不能同时修改但即使事务未提交也会读取到其它事务未提交的内容(可能会被回滚)。会有脏读、重复读、幻读的问题读取未提交的数据也被称之为脏读Dirty Read。
特点最低级别任何情况都无法保证
数据库锁情况
读取数据未加锁每次都读到最新数据性能最好写入数据只对数据增加行级共享锁写完释放
Read Committed(读已提交)
当前事务只能读取到其它事务已提交的数据。因同一事务的其它实例在该实例处理期间可能会有新的commit所以同一select可能返回不同结果这就是所谓的不可重复读Nonrepeatable Read。该隔离级别解决了脏读问题但还是会存在重复读、幻读问题。
特点避免脏读
脏读解决方案基于乐观锁理论的MVCC多版本并发控实现
数据库锁情况
读取数据加行级共享锁读到时才加锁读完后立即释放写入数据在更新时的瞬间对其加行级排它锁直到事务结束才释放
Repeatable Read(可重复读)
限制了读取数据时不可以进行修改所以解决了不能重复读的问题。但是读取范围数据的时候是可以插入或删除数据所以还会存在**幻读Phantom Read**问题。
幻读 是户读取某一范围的数据行时另一个事务又在该范围内插入了新行当该用户再读取该范围的数据行时会发现有新的“幻影” 行。
特点避免脏读、不可重复读。MySQL默认事务隔离级别
不可重复读解决方案基于乐观锁理论的MVCC多版本并发控实现
数据库锁情况
读取数据开始读取的瞬间对其增加行级共享锁直到事务结束才释放写入数据开始更新的瞬间对其增加行级排他锁直到事务结束才释放
Serializable(可串行化)
所有事务都是进行串行化顺序执行的。可以避免脏读、不可重复读与幻读所有并发问题。但该事务隔离级别下事务执行很耗性能。
特点避免脏读、不可重复读、幻读
数据库锁情况
读取数据先对其加表级共享锁 直到事务结束才释放写入数据先对其加表级排他锁 直到事务结束才释放
Spring事务机制
实现方式
在Spring中事务有两种实现方式
编程式事务管理 编程式事务管理使用TransactionTemplate或直接使用底层的PlatformTransactionManager声明式事务管理 建立在AOP之上的。其本质是对方法前后进行拦截然后在目标方法开始之前创建或者加入一个事务在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务管理不需要入侵代码通过Transactional就可以进行事务操作更快捷而且简单
提交方式
默认情况下数据库处于自动提交模式。每一条语句处于一个单独的事务中在这条语句执行完毕时如果执行成功则隐式的提交事务如果执行失败则隐式的回滚事务。 对于正常的事务管理是一组相关的操作处于一个事务之中因此必须关闭数据库的自动提交模式。不过这个我们不用担心Spring会将底层连接的自动提交特性设置为false。也就是在使用Spring进行事物管理的时候Spring会将是否自动提交设置为false等价于JDBC中的 connection.setAutoCommit(false);在执行完之后在进行提交connection.commit(); 。
事务隔离级别
隔离级别是指若干个并发的事务之间的隔离程度。
Transactional(isolation Isolation.READ_UNCOMMITTED)
public void addGoods(){......
}枚举类Isolation中定义了五种隔离级别
DEFAULT默认值。表示使用底层数据库的默认隔离级别。对大部分数据库通常这值就是READ_COMMITTEDREAD_UNCOMMITTED该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读不可重复读和幻读因此很少使用该隔离级别READ_COMMITTED该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读这也是大多数情况下的推荐值REPEATABLE_READ该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询并且每次返回的记录都相同。该级别可以防止脏读和不可重复读SERIALIZABLE所有的事务依次逐个执行这样事务之间就完全不可能产生干扰也就是说该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别
事务传播行为
事务的传播性一般用在事务嵌套的场景如一个事务方法里面调用了另外一个事务方法那两个方法是各自作为独立的方法提交还是内层事务合并到外层事务一起提交这就需要事务传播机制配置来确定怎么样执行。
Transactional(propagationPropagation.REQUIRED)
public void addGoods(){......
}枚举类Propagation中定义了七种事务传播机制如下
REQUIREDrequired要求Spring默认当前存在事务则加入该事务当前没有事务则创建一个新的事务REQUIRES_NEWrequires_new要求新的创建一个新事务如果存在当前事务则挂起该事务SUPPORTSsupports支持如果当前存在事务则加入当前事务如果当前没有事务就以非事务方法执行NOT_SUPPORTEDnot_supported不支持始终以非事务方式执行如果当前存在事务则挂起当前事务NEVERnever都不不使用事务如果当前事务存在则抛出异常MANDATORYmandatory强制如果当前存在事务则加入当前事务如果当前事务不存在则抛出异常NESTEDnested嵌套如果当前事务存在则在嵌套事务中执行否则REQUIRED的操作一样开启一个事务
事务回滚规则
指示Spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。Spring事务管理器会捕捉任何未处理的异常然后依据规则决定是否回滚抛出异常的事务。 默认配置下Spring只有在抛出的异常为运行时unchecked异常时才回滚该事务也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)而抛出checked异常则不会导致事务回滚。 可以明确的配置在抛出那些异常时回滚事务包括checked异常。也可以明确定义那些异常抛出时不回滚事务。
事务常用配置 readOnly 该属性用于设置当前事务是否为只读事务设置为true表示只读false则表示可读写默认值为false。例如Transactional(readOnlytrue) rollbackFor 该属性用于设置需要进行回滚的异常类数组当方法中抛出指定异常数组中的异常时则进行事务回滚。例如指定单一异常类Transactional(rollbackForRuntimeException.class)指定多个异常类Transactional(rollbackFor{RuntimeException.class, Exception.class}) rollbackForClassName 该属性用于设置需要进行回滚的异常类名称数组当方法中抛出指定异常名称数组中的异常时则进行事务回滚。例如指定单一异常类名称Transactional(rollbackForClassName”RuntimeException”)指定多个异常类名称Transactional(rollbackForClassName{“RuntimeException”,”Exception”}) noRollbackFor 该属性用于设置不需要进行回滚的异常类数组当方法中抛出指定异常数组中的异常时不进行事务回滚。例如指定单一异常类Transactional(noRollbackForRuntimeException.class)指定多个异常类Transactional(noRollbackFor{RuntimeException.class, Exception.class}) noRollbackForClassName 该属性用于设置不需要进行回滚的异常类名称数组当方法中抛出指定异常名称数组中的异常时不进行事务回滚。例如指定单一异常类名称Transactional(noRollbackForClassName”RuntimeException”)指定多个异常类名称Transactional(noRollbackForClassName{“RuntimeException”,”Exception”}) propagation 该属性用于设置事务的传播行为。例如Transactional(propagationPropagation.NOT_SUPPORTED,readOnlytrue) isolation 该属性用于设置底层数据库的事务隔离级别事务隔离级别用于处理多事务并发的情况通常使用数据库的默认隔离级别即可基本不需要进行设置 timeout 该属性用于设置事务的超时秒数默认值为-1表示永不超时
失效场景
Transactional 应用在非 public 修饰的方法上数据库引擎要不支持事务由于propagation 设置错误导致注解失效rollbackFor 设置错误Transactional 注解失效方法之间的互相调用也会导致Transactional失效异常被你的 catch“吃了”导致Transactional失效
