前言
数据库应该是所有后端开发都会涉及的,数据库事务,很多业务场景可能并不要求很高,而且也很少出现,经常出现在高并发,高流量的情况下,在未来迎接挑战的时候,需要掌握相关的知识,这里希望能够简单介绍下,总结一点知识点和注意点。
事务
目前接触到的最多的就是通过spring来控制事务处理。这里就重点讲一下spring事务的知识点。
事务的目的:
- 数据一致:指的是事务提交能够正确执行,而且持久到数据库,事务回滚能够恢复到事务执行之前的状态。
- 操作隔离:多个事务操作应该相互独立,不干扰。
这里就引出了事务的四个特性:
- 原子性 (atomicity):强调事务的不可分割.
- 一致性 (consistency):事务的执行的前后数据的完整性保持一致.
- 隔离性 (isolation):一个事务执行的过程中,不应该受到其他事务的干扰
- 持久性(durability) :事务一旦结束,数据就持久到数据库
我们把严格遵循ACID
特性的事务成为刚性事务
。
期望最终一致性,在事务执行的中间状态允许暂时不遵循ACID
特性的事务称为柔性事务
。
事务常见异常
对于事务异常,总的可以分为三类:
- 脏读:当前有事务在运行,另一个线程获取到数据,前面的事务可能回滚,所以出现了脏读,这个现象在事务隔离级别
Read uncommitted
时会出现。 - 不可重复读:事务a对数据读取了两次,再此过程中,事务B对数据进行了修改,这时,事务a前后两次数据读取就不一致了,当事务隔离级别设置为
Read uncommitted
、Read committed
时会出现。 - 幻读:事务a对数据读取两次,在此过程中,事务B对数据进行了新增和删除,这时,事务a前后两次获取的数据量就不一致了。当事务隔离级别设置为
Read uncommitted
、Read committed
、Repeatable read
针对事务常见异常,我们可知,数据库可以设置对应的事务隔离级别,针对不同的业务进行不同的配置。
- Read uncommitted:设置该级别,事务b可以读取事务a未提交的事务。
后续可以跟进下具体的原理。
- Read committed:设置该级别,事务b只能获取事务a已经提交的事务,但是不能保证事务b在事务a提交前后数据保持一致。
- Repeatable read:设置该级别,事务a如果已经获取了某条数据,事务b在事务a完成之前,是不允许修改该数据的,但是可以修改其他数据,这就导致了幻读。
注:Mysql的默认隔离级别就是Repeatable read。 - Serializable:所有事务顺序执行。
事务死锁
在高并发的情况下,为了让数据更可靠,不可避免的会进行事务,事务会对表和数据进行加锁。这也就要考虑事务死锁的问题。
常见的锁从不同的分类可以归类成:
- 行锁、表锁
- 共享锁、排它锁(独占锁)
后续添加sql展示
具体使用场景待分析
事务死锁场景举例:
- 1.转账问题:
a和b互相转账,(a)a给b转账,a扣钱,锁定a数据,尝试获取b加钱的事务,(b)b给a转账,b扣钱,锁定b数据,尝试获取a加钱的事务。
解决方案:(1)按照账号顺序,就是说,始终a先处理事务。(2)提前获取a和b的事务。
Spring事务
Spring使用AOP(面向切面编程)来实现声明式事务,也可以使用编程式事务来控制事务,需要了解动态代理
和AOP增强
。
关于AOP增强
可以适当了解下,主要是五种增强方式
。
Spring事务抽象
- PlatformTransactionManager 事务管理器,听名字就知道它是管理事务的操作的,它只包含三个方法。获取事务,回顾事务,提交事务
- TransactionDefiition 定义事务的类型,事务包含很多属性,是否可读,事务隔离级别,事务传播级别。通过事务的定义,我们根据定义获取特定的事务。
- TransactionStatus 代表一个事务运行的状态,事务管理器通过状态可以知道事务的状态信息,然后进行事务的控制。事务是否完成,是否是新的事务,是不是只能回滚等。
Spring事务拦截
声明式事务是一种环绕增强,对应接口为MethodInterceptor,事务增强对该接口的实现为TransactionInterceptor,查看父类接口可以看到对应声明式事务的提交,当然这里的提交也可以用编程式事务处理。
Transaction对象是由TransactionSynchronizationManager来控制的。其判断当前的数据源是否有连接对应,用的是ThreadLocal,所以,事务是单线程的
Spring五个事务隔离级别和七个事务传播行为
ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别,使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应
ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别,它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读,不可重复读和幻像读
ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现,但是可能会出现不可重复读和幻像读。
ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读,不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外,还保证了避免下面的情况产生(不可重复读)。
ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读,不可重复读外,还避免了幻像读。
PROPAGATION_REQUIRED 如果存在一个事务,则支持当前事务。如果没有事务则开启一个新的事务。
PROPAGATION_SUPPORTS 如果存在一个事务,支持当前事务。如果没有事务,则非事务的执行。但是对于事务同步的事务管理器,PROPAGATION_SUPPORTS与不使用事务有少许不同。
PROPAGATION_MANDATORY 如果已经存在一个事务,支持当前事务。如果没有一个活动的事务,则抛出异常。
PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在,则将这个存在的事务挂起。
PROPAGATION_NOT_SUPPORTED 总是非事务地执行,并挂起任何存在的事务。
PROPAGATION_NEVER 总是非事务地执行,如果存在一个活动事务,则抛出异常
PROPAGATION_NESTED如果一个活动的事务存在,则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行
待补充示例:
单线程事务
多线程事务
使用countdownlatch完成
分布式事务
解决方案分析
mq
网友评论