前言

数据库应该是所有后端开发都会涉及的，数据库事务，很多业务场景可能并不要求很高，而且也很少出现，经常出现在高并发，高流量的情况下，在未来迎接挑战的时候，需要掌握相关的知识，这里希望能够简单介绍下，总结一点知识点和注意点。

事务

目前接触到的最多的就是通过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