数据库事务详解

事务-1-数据库事务

今天聊一聊数据库的事务，这里以MySQL为例子。

在MySQL中，事务（Transaction）是一组SQL操作的集合，这些操作要么全部成功执行，要么全部失败回滚，确保数据的一致性和完整性。事务具有以下四个关键特性，通常称为ACID特性：

原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不完成。如果事务中的任何操作失败，整个事务将回滚到最初状态。事务中的所有元素必须作为一个整体提交或回滚，如果事务中的任何元素失败，则整个事务将失败。
一致性（Consistency）：事务确保数据库从一个一致状态转换到另一个一致状态。即使在事务执行过程中出现错误，数据库也不会处于不一致的状态。大白话来说就是最终结果是我们预期的那样，比如A给B转钱100块，如果转成功了那么就是A少一百块，B多一百块；如果失败了，那么A和B账户里面的钱还是原封不动的。
隔离性（Isolation）：多个事务并发执行时，每个事务的操作与其他事务隔离，互不干扰。MySQL提供了不同的隔离级别（如读未提交、读已提交、可重复读(innodb默认隔离级别)、串行化）来控制事务之间的可见性。
持久性（Durability）：一旦事务提交，其对数据库的修改就是永久性的，即使系统崩溃也不会丢失。

还有一点值得注意的那就是隐式事务和显式事务

执行单条SQL语句的时候，例如insert、update、delete操作的时候，数据库自动开启事务、提交或回滚事务。

Mysql默认是提交事务的。MySQL 默认开启事务自动提交模式，每条 SOL 语句都会被当做一个单独的事务自动执行。

1.MySQL中的事务操作

开始事务：使用START TRANSACTION或BEGIN语句开始一个新事务。
提交事务：使用COMMIT语句提交事务，使所有修改永久生效。
回滚事务：使用ROLLBACK语句回滚事务，撤销所有未提交的修改。

2.具体分析

数据库名字，trans_db, 这里假设有两个数据库表，如下sql建表语句

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;-- ----------------------------
-- Table structure for account
-- ----------------------------
DROP TABLE IF EXISTS `account`;
CREATE TABLE `account`  (`account_id` int NOT NULL AUTO_INCREMENT COMMENT '账户ID',`uid` int NULL DEFAULT NULL COMMENT '用户ID，该账户属于哪个用户的',`money` int NULL DEFAULT NULL COMMENT '账户金额,测试所以用int',PRIMARY KEY (`account_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci ROW_FORMAT = Dynamic;-- ----------------------------
-- Records of account
-- ------------------------------ ----------------------------
-- Table structure for user
-- ----------------------------
DROP TABLE IF EXISTS `user`;
CREATE TABLE `user`  (`uid` int NOT NULL AUTO_INCREMENT COMMENT '用户ID',`name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,`age` int NULL DEFAULT NULL,PRIMARY KEY (`uid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci ROW_FORMAT = Dynamic;-- ----------------------------
-- Records of user
-- ----------------------------
SET FOREIGN_KEY_CHECKS = 1;

上面是一个很简单的用户账户的两张表。

有三个账户。

在这里插入图片描述

每个账户归属于各自的用户，里面都有1000块钱。

①简单事务操作

**事务操作：**用户1给用户2转100块钱，那么1账户-100，2账户+100。

在这里插入图片描述

从上图看出，start transaction还有begin都可以开启一个事务，在事务提交之前，对数据库所做的操作，我们在右边是看不到的。只有在commit之后才会看到数据库中的修改。

在这里插入图片描述

可以看到commit提交之后，可以在数据库中看到对应的操作。

**回滚操作：**用户2给用户1转100块钱，但是我们在事务中回滚了，然后再提交，故会回到事务开始前的状态。

在这里插入图片描述

然后提交后，发现数据是原封不动的。

savepoint操作：1给2转500块钱，2给1转100块钱，但是第二步操作是失败了。需要回到第一步操作结束的时候。

在这里插入图片描述

在commit之前，中间的sql语句执行，对于我们而言都是不可见的。

上图中，savepoint保存了一个点，然后我们可以通过rollback to savepoint 名字来让数据回到那个保存点。

②隔离级别

select @@transaction_isolation;查看当前的隔离级别

事务的隔离性是通过数据库锁的机制实现的。

产生的问题概览：

事务 A、B 交替执行，事务 A 读取到事务 B 未提交的数据，这就是脏读。
在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。
事务 A 查询一个范围的结果集，另一个并发事务 B 往这个范围中插入 / 删除了数据，并静悄悄地提交，然后事务 A 再次查询相同的范围，两次读取得到的结果集不一样了，这就是幻读。

在这里插入图片描述

原文链接：https://blog.csdn.net/zch981964/article/details/128099297

并发性能从上到下依次递减

不可重复读 vs 幻读：（引用知乎大佬的话https://www.zhihu.com/question/392569386，下面暖猫Suki的回答）

“脏读”指读到了未提交的数据，然后基于这个数据做了一些事情，结果做完发现数据被回滚了。可以理解为领导还没下达正式任务你就凭着自己的揣摩开始干活，结果活干完了，任务的内容被改了。“不可重复读”好一点，读到的是已提交的数据，比如某个读事务持续时间比较长，期间多次读取某个元组，每次读到的都是被别人改过并已提交的不同数据。可以理解为在执行任务的过程中，领导的指令一直在变。但好歹是正式下达的指令。“幻读”是指读的过程中，某些元组被增加或删除，这样进行一些集合操作，比如算总数，平均值等等，就会每次算出不一样的数。所以“不可重复读”和“幻读”都是读的过程中数据前后不一致，只是前者侧重于修改，后者侧重于增删。个人认为，严格来讲“幻读”可以被称为“不可重复读”的一种特殊情况。但是从数据库管理的角度来看二者是有区别的。解决“不可重复读”只要加行级锁就可以了。而解决“幻读”则需要加表级锁，或者采用其他更复杂的技术，总之代价要大许多。这是搞数据库的那帮家伙非要把这两者区分开的动机吧。
// 这里解决幻读需要加表级锁这里我不是很清楚，下面评论有说 不需要锁表，MVCC配合索引上的next key lock的，这个本文章就不深究了，在后续文章中分析作者：暖猫Suki
链接：https://www.zhihu.com/question/392569386/answer/1434210648
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1.读未提交

所有事务都可以看到其他未提交事务的执行结果。本隔离级别是最低的隔离级别，虽然拥有不错的并发处理能力及较低的系统开销，但很少用于实际应用。因为一个最大的问题就是会读取到脏数据。

set session transaction isolation level read uncommitted;这句话，可以设置当前会话事务隔离级别为读未提交

下面举一个例子，开启两个命令行窗口，左边开启的事务负责修改数据，右边的窗口事务负责查询。

在这里插入图片描述

可以看到，左边是账户1扣50块钱，左边还未提交事务呢，右边的黑窗口里面已经查到了。但是navicat里面为啥看不到呢？因为navicat还是用的默认的隔离级别啊，我只是设置了当前会话的隔离级别，也就是那俩黑窗口是读未提交的。最后提交就可以更新到数据库了。

很显然哦，假如有这样一个例子，还是关于转账的，1有1000块，2有1000块，3有1000块。有如下两个事务

银行系统给用户1添加100块钱

begin; -- 1
update account set money = money + 100 where uid = 1; -- 2
commit; -- 3

银行系统查询用户1账户里面的余额

begin; -- 4
select * from account; -- 5
commit; -- 6

这两个事务操作是并发执行的。

但是，并发啊！！各位懂吗？

假如MySQL此时执行到上面的语句2的时候，还没来得及执行语句3【提交事务】，这个时候恰好执行了语句5，由于是读未提交，故此时读取到uid为1的账户里面有1100块钱.

在这里插入图片描述

可以看到，上图中，右边navicat里面，提交之前是看不到的。如果提交之后

在这里插入图片描述

就可以看到了。

如果，假如说如果，事务B失败回滚了，用户1账户应该还是1000块钱；但是在事务A中，读取到的数据是1100块钱，还有其他的业务操作的话，那么，事务A中用的就是脏数据了！！

2.读已提交

set session transaction isolation level read committed

这个可以避免脏读，但是会导致不可重复读。

脏读由于是读已提交的，故在事务里面读取的都是别的事务提交过的数据，故不会出现脏读了，这里就不详细演示了。

在这里插入图片描述

从上面图中看出，绿色框框是在左边事务提交之前读取的，可以看到都是1000块钱，在左边事务提交之后，红色框框查询的就是900块钱了。

不可重复读：同一事务里面，不同时刻读取到的同一个值，他是不一样的，下面就来演示一下。

现在有两个事务并发，事务1需要查询一次账户1的余额，过一会又想查询一次账户1的余额；事务2在事务1查询第一次之后，修改了账户1的余额，然后事务2提交了事务。

在这里插入图片描述

可以看到在事务1里面，两次同样的查询是不一样的。

3.可重复读（default）

set session transaction isolation level repeatable read;

在这里插入图片描述

按照上面标注的顺序执行。可以看到在事务1里面，读取到的结果都是一样的。

扩展一下，死锁问题

思考一下，假如有两个事务，隔离级别是可重复读，事务1给账户1扣五百块钱，事务2也给账户1扣五百块钱。假如在事务1里面先读取到账户1，是1000块钱，执行update语句，不提交，此时在事务2里面也执行update扣五百的语句，会怎么样呢？

在这里插入图片描述

上面的图答案很明显，会锁住！如果事务1一直不提交的话，甚至会出现锁超时的情况【如果没有超时，在等待期间如果事务1提交了，会看到事务2会马上输出执行结果的】

mysql> update account set money = money - 500 where uid = 1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
-- MySQL 提供了锁超时机制（innodb_lock_wait_timeout），如果一个事务等待锁的时间超过设定的阈值，会自动回滚并释放锁。

在这里插入图片描述

上面的图给出了完整流程。

事务并发会导致有死锁的问题！在日常中，死锁是不可能百分之百避免的

4.串行化

SERIALIZABLE

set session transaction isolation level serializable;

这个就不详细演示了。

串行化的实现采用的是读写都加锁的原理。

在这里插入图片描述

/*
按照上面的顺序，语句4加了共享锁【读锁】，语句5执行的时候需要加上排它锁【写锁】，产生了死锁条件了。故左边窗口会在语句5这里卡住了，这个时候把右边窗口事务提交掉，释放了读锁，故此时左边窗口的线程就可以继续向下执行了。降低事务的隔离级别，上面的操作就不会出现这个问题。
*/

串行化的情况下，对于同一行事务，**写会加写锁，读会加读锁。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。**这避免了所有的并发问题，但是锁的更多了。。。

使用了串行化隔离级别时，在这个事务没有被提交之前，其他的线程，只能等到当前事务提交完成之后，才能进行操作，这样会非常耗时，非常影响数据库的性能，通常情况下，不会使用这种隔离级别。

3.SpringBoot和事务

搭建好SpringBoot项目，配置好数据库的连接后。。。

①声明式

@Transactional注解：

@Transactional 是 Spring 框架中用于管理事务的核心注解。它可以应用于类或方法级别，用于声明事务的边界、传播行为、隔离级别、超时时间等属性。

@Transactional 可以标注在类或方法上：

标注在类上：表示该类的所有公共方法都启用事务管理。
标注在方法上：表示该方法启用事务管理。

@Service
public class AccountService {@Autowiredprivate AccountRepository accountRepository;@Transactionalpublic void transfer(Long fromId, Long toId, Double amount) {// 逻辑}
}

@Transactional 注解仅在以下条件下生效：

方法必须是 public：Spring 默认只对公共方法启用事务代理。
方法必须通过代理调用：如果方法在同一个类中直接调用，事务不会生效（因为 Spring 使用代理模式）。
Spring 事务管理器已配置：确保在 Spring 配置中启用了事务管理。

// 先来看看该注解长啥样
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {@AliasFor("transactionManager")String value() default ""; //用于指定选择的事务管理器@AliasFor("value")String transactionManager() default "";String[] label() default {};//事务的传播行为，默认是REQUIREDPropagation propagation() default Propagation.REQUIRED;//事务的隔离级别，默认值采用Default，即基于当前数据库事务的隔离级别Isolation isolation() default Isolation.DEFAULT;//事务的超时时间int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;String timeoutString() default "";boolean readOnly() default false;//用于指定会触发事务回滚的异常类型Class<? extends Throwable>[] rollbackFor() default {};String[] rollbackForClassName() default {};Class<? extends Throwable>[] noRollbackFor() default {};String[] noRollbackForClassName() default {};
}
// 上文中关于@Transactional也有介绍

@Transactional核心属性

`propagation`（传播行为）

定义事务的传播行为，即当前方法如何与已有事务交互。默认值为 Propagation.REQUIRED。

REQUIRED：如果当前存在事务，则加入该事务；否则创建一个新事务。【默认的】
REQUIRES_NEW：总是创建一个新事务，如果当前存在事务，则挂起当前事务。
NESTED：如果当前存在事务，则在嵌套事务中执行。
SUPPORTS：如果当前存在事务，则加入该事务；否则以非事务方式执行。
NOT_SUPPORTED：以非事务方式执行，如果当前存在事务，则挂起当前事务。
MANDATORY：如果当前存在事务，则加入该事务；否则抛出异常。
NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

`isolation`（隔离级别）

定义事务的隔离级别，用于控制事务之间的可见性。默认值为 Isolation.DEFAULT（使用数据库的默认隔离级别）。

DEFAULT：使用数据库的默认隔离级别。
READ_UNCOMMITTED：读未提交，最低隔离级别。
READ_COMMITTED：读已提交。
REPEATABLE_READ：可重复读。
SERIALIZABLE：串行化，最高隔离级别。

`timeout`（超时时间）

定义事务的超时时间（以秒为单位）。如果事务在指定时间内未完成，则自动回滚。默认值为 -1（不超时）。长事务会有对数据库有较长的锁定，长时间会占用数据库资源。

`readOnly`（只读事务）

定义事务是否为只读。只读事务可以优化数据库性能，避免不必要的写操作。默认值为 false。

`rollbackFor` 和 `noRollbackFor`

定义哪些异常触发回滚，哪些异常不触发回滚。

rollbackFor：指定触发回滚的异常类型（默认为 RuntimeException 和 Error）。
noRollbackFor：指定不触发回滚的异常类型。

用法演示

// 1.最基本的用法--声明式事务
@Override
@Transactional
public void saveSimple1(Account account) {System.out.println("【需要插入的数据】：" + account);accountDao.insert(account);throw new RuntimeException("抛出异常额~~~");
}

在方法上加上这个@Transactional注解，即可保证该方法内为一个事务，上面例子，抛出异常后会rollback，即数据库数据不变。

// 2.外层函数声明式事务， 内层没有
@Override
@Transactional
public void saveSimple2(Account account) {System.out.println("【需要插入的数据】：" + account);fun1(account);throw new RuntimeException("抛出异常额~~~");
}//@Transactional  这个注解加上了，在默认情况下，效果是一样的
public void fun1(Account account) {accountDao.insert(account);
}

很显然嘛，可以想象默认情况下，最外层的把内层所有的包起来了，形成整个事务。

// 3.同类中，外层没有，内层有
@Override
public void saveSimple3(Account account) {System.out.println("【需要插入的数据】：" + account);fun2(account);throw new RuntimeException("抛出异常额~~~");
}
@Transactional
public void fun2(Account account) {accountDao.insert(account);
}

**事务会失效！**为啥啊。

// 4.不同类中的方法声明式事务, 外层没有注解
// AccountServiceImpl.class
@Override
public void saveSimple4(Account account) {accountDao.insert(account);userService.updateByUserId(account.getUid()); // 调用UserServiceImpl的事务方法throw new RuntimeException("抛出异常额~~~不同类中");
}
// UserServiceImpl.class
@Override
@Transactional
public void updateByUserId(Integer uid) {User user = userDao.selectById(uid);user.setName(user.getName() + "t");userDao.updateById(user);// throw new RuntimeException("抛出异常额~~~不同类中");  //注释点【1】
}

都没有回滚。为啥啊。

这个先说结论，accountDao.insert(account);这一句不会滚很正常。userService.updateByUserId(account.getUid());是另一个类的事务里面，但是那个正常执行了呀。抛异常又不是在事务里面抛的，所以都不会回滚呐。

假如说，将上面注释点【1】解开，那么，就是accountDao.insert(account);不会滚，userService.updateByUserId(account.getUid());回滚了。！！！

事务为什么会失效？

SpringBoot事务自动配置：

Spring 声明式事务基于 AOP 实现。

与数据库打交道，我们需要引入jdbc的依赖，导入这个场景

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-jdbc</artifactId>
</dependency><!--有时候我们引入的mybatis的-->
<dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</artifactId><version>3.3.2</version>
</dependency>
<!--从mybatis依赖往上看，发现它其实也引入了spring-boot-starter-jdbc--><!--最后，追根溯源，就是这个包-->
<dependency><groupId>org.springframework</groupId><artifactId>spring-jdbc</artifactId>
</dependency>

在SpringBoot原理分析-1中，我们知道导入这个场景，就有了事务支持的话，肯定是用了自动装配了。

那么，我们去spring-boot-autoconfigure中看一下，会发现其有transaction这个包！

在这里插入图片描述

.....
public class TransactionAutoConfiguration {//=================== 显示定义了以下的三个bean@Bean@ConditionalOnMissingBeanpublic TransactionManagerCustomizers platformTransactionManagerCustomizers(ObjectProvider<PlatformTransactionManagerCustomizer<?>> customizers) {return new TransactionManagerCustomizers(customizers.orderedStream().collect(Collectors.toList()));}@Bean@ConditionalOnMissingBean@ConditionalOnSingleCandidate(ReactiveTransactionManager.class)public TransactionalOperator transactionalOperator(ReactiveTransactionManager transactionManager) {return TransactionalOperator.create(transactionManager);}@Configuration(proxyBeanMethods = false)@ConditionalOnSingleCandidate(PlatformTransactionManager.class)public static class TransactionTemplateConfiguration {@Bean@ConditionalOnMissingBean(TransactionOperations.class)public TransactionTemplate transactionTemplate(PlatformTransactionManager transactionManager) {return new TransactionTemplate(transactionManager);}}//================================================// 重点配置是在内部类EnableTransactionManagementConfiguration中// 该类对Jdk动态代理和CGlib动态代理两种方式分别作了配置@Configuration(proxyBeanMethods = false)@ConditionalOnBean(TransactionManager.class)@ConditionalOnMissingBean(AbstractTransactionManagementConfiguration.class)public static class EnableTransactionManagementConfiguration {@Configuration(proxyBeanMethods = false)@EnableTransactionManagement(proxyTargetClass = false)@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false")public static class JdkDynamicAutoProxyConfiguration {}@Configuration(proxyBeanMethods = false)// 指示是否创建基于子类 （CGLIB） 的代理 （true） 而不是基于标准 Java 接口的代理 （false）。@EnableTransactionManagement(proxyTargetClass = true)@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",matchIfMissing = true)public static class CglibAutoProxyConfiguration {}}
.........................}

这个内部类中并没有配置事务相关的bean，那么关键是在@EnableTransactionManagement注解中

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
//使用@Import注解导入了一个TransactionManagementConfigurationSelector
@Import(TransactionManagementConfigurationSelector.class)
public @interface EnableTransactionManagement {...}

下面来看一下TransactionManagementConfigurationSelector

public class TransactionManagementConfigurationSelector extends AdviceModeImportSelector<EnableTransactionManagement> {
.........@Overrideprotected String[] selectImports(AdviceMode adviceMode) {// 如果adviceMode是代理模式，那么就走其对应分支，这里仅分析动态代理的情况咯switch (adviceMode) {case PROXY:return new String[] {AutoProxyRegistrar.class.getName(),ProxyTransactionManagementConfiguration.class.getName()};case ASPECTJ:return new String[] {determineTransactionAspectClass()};default:return null;}}
..........}

也就是说，ProxyTransactionManagementConfiguration才是真正的配置类！

public class ProxyTransactionManagementConfiguration extends AbstractTransactionManagementConfiguration {@Bean(name = TransactionManagementConfigUtils.TRANSACTION_ADVISOR_BEAN_NAME) // 1@Role(BeanDefinition.ROLE_INFRASTRUCTURE)/*这是一个 Spring AOP 的 Advisor，它将事务拦截器（TransactionInterceptor）与事务属性源（TransactionAttributeSource）结合起来，用于在方法调用时应用事务管理。*/public BeanFactoryTransactionAttributeSourceAdvisor transactionAdvisor(TransactionAttributeSource transactionAttributeSource, TransactionInterceptor transactionInterceptor) {BeanFactoryTransactionAttributeSourceAdvisor advisor = new BeanFactoryTransactionAttributeSourceAdvisor();advisor.setTransactionAttributeSource(transactionAttributeSource);advisor.setAdvice(transactionInterceptor);if (this.enableTx != null) {advisor.setOrder(this.enableTx.<Integer>getNumber("order"));}return advisor;}@Bean // 2 -------transactionAttributeSource bean@Role(BeanDefinition.ROLE_INFRASTRUCTURE)public TransactionAttributeSource transactionAttributeSource() {/*AnnotationTransactionAttributeSource：这是一个具体的实现类，它从方法或类上的 @Transactional 注解中解析事务属性。*/return new AnnotationTransactionAttributeSource();}@Bean // 3 ---@Role(BeanDefinition.ROLE_INFRASTRUCTURE)//这是一个 Spring AOP 的拦截器，用于在方法调用时执行事务管理逻辑。public TransactionInterceptor transactionInterceptor(TransactionAttributeSource transactionAttributeSource) {TransactionInterceptor interceptor = new TransactionInterceptor();// 将事务属性源设置到拦截器中。interceptor.setTransactionAttributeSource(transactionAttributeSource);if (this.txManager != null) {// 如果 txManager 属性不为空，则将事务管理器设置到拦截器中。interceptor.setTransactionManager(this.txManager);}return interceptor;}
}

上面有三个Bean，第一个Bean将第二个，第三个Bean结合起来。第三个Bean用到了第二个Bean，用来设置事务属性源。这里是注解。

接下来看看这个TransactionInterceptor

public class TransactionInterceptor extends TransactionAspectSupport implements MethodInterceptor, Serializable {// 里面有一个invoke方法@Override@Nullablepublic Object invoke(MethodInvocation invocation) throws Throwable {Class<?> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);return invokeWithinTransaction(invocation.getMethod(), targetClass, new CoroutinesInvocationCallback() {@Override@Nullablepublic Object proceedWithInvocation() throws Throwable {return invocation.proceed();}@Overridepublic Object getTarget() {return invocation.getThis();}@Overridepublic Object[] getArguments() {return invocation.getArguments();}});}
}

SpringBoot事务执行过程

首先思考一下，如果要我们手动实现基于aop的事务，该怎么做呢。

// service
public Object getUser(Integer uid) {return userMapper.getById(uid);
}

无非就是环绕通知around来实现嘛，最后达成这样一个效果

public .....  invoke ( 真实对象 o ) {before操作;o.getUser(uid);after操作
}

但是Spring的会自动回滚耶，那我们就多加一点儿东西嘛

public .....  invoke ( 真实对象 o ) {连接 Connect connection;try{before操作;得到连接connection;o.getUser(uid);after操作事务提交connection.commit();} catch( 异常 ) {connection.rollback()}
}

这样不就可以了吗，Spring是这样做的吗？解下来通过一个例子来追踪一下调用过程。

// Controller
// 7.源码追踪
@PostMapping("/add7")
public R add7(@RequestBody Account account) {accountService.saveSimple7(account); // 将这里打上断点，debugreturn R.success();
}
// service
@Override
@Transactional
public void saveSimple7(Account account) {Integer uid = account.getUid();int i = 1 / uid;accountDao.insert(account); // 将这里也打上断点，debug
}

在这里插入图片描述

这个accountService怎么是这个样子？？

然后我们点击进入方法，来到了CglibAopProxy类中的下面的方法了。

在这里插入图片描述

retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();

执行到，这一行代码了，创建方法代理对象，然后执行proceed方法

@Override
@Nullable
public Object proceed() throws Throwable {try {// 主要是这一行,调用父类的方法return super.proceed(); }catch (RuntimeException ex) {throw ex;}catch (Exception ex) {..............}
}

ReflectiveMethodInvocation是它的父类：用来处理方法调用的拦截器链，因为可能不只有事务@Transactional，还可能会有我们自定义的其他方法拦截器，比如说日志记录aop之类的

@Override
@Nullable
public Object proceed() throws Throwable {// 检查是否到达拦截器链的末尾--责任链设计模式？if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {return invokeJoinpoint();}// 获取下一个拦截器或动态方法匹配器Object interceptorOrInterceptionAdvice =this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);// 处理动态方法匹配器,这里不清楚if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {........}else {//如果当前对象是一个普通的拦截器（MethodInterceptor），则直接调用其 invoke() 方法。// 执行到这里了====================return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this); // 进入这里}
}

拦截器链的执行：
- Spring AOP 使用拦截器链来实现方法调用的增强（如事务管理、日志记录等）。
- 每个拦截器都可以在目标方法执行前后插入自定义逻辑。
递归终止条件：
- 这段代码是递归调用 proceed() 的终止条件。
- 当所有拦截器都执行完毕后，最终调用目标方法。
责任链模式：
- Spring AOP 使用了责任链模式（Chain of Responsibility），每个拦截器都可以决定是否继续调用下一个拦截器。
- 通过递归调用 proceed()，控制权在拦截器链中逐级传递。

假设有以下拦截器链：

拦截器 A
拦截器 B
目标方法

调用流程如下：

调用 proceed()，currentInterceptorIndex 从 -1 变为 0，执行拦截器 A 的 invoke()。
在拦截器 A 的 invoke() 中，调用 proceed()，currentInterceptorIndex 从 0 变为 1，执行拦截器 B 的 invoke()。
在拦截器 B 的 invoke() 中，调用 proceed()，currentInterceptorIndex 从 1 变为 2。
此时，currentInterceptorIndex == interceptorsAndDynamicMethodMatchers.size() - 1，调用 invokeJoinpoint()，执行目标方法。
目标方法执行完毕后，逐级返回结果，最终返回给调用方。

之后我们来到了TransactionInterceptor，它继承自TransactionAspectSupport

@Override
@Nullable
public Object invoke(MethodInvocation invocation) throws Throwable {..................... // 执行这个，是父类TransactionAspectSupport的方法return invokeWithinTransaction(invocation.getMethod(), targetClass, new CoroutinesInvocationCallback() {@Override@Nullablepublic Object proceedWithInvocation() throws Throwable {return invocation.proceed();}@Overridepublic Object getTarget() {return invocation.getThis();}@Overridepublic Object[] getArguments() {return invocation.getArguments();}});
}

TransactionAspectSupport

@Nullable
protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,final InvocationCallback invocation) throws Throwable {// 这个方法有点长。。。只截取重要部分//  处理普通事务// 平台事务管理器，用于管理传统的事务。PlatformTransactionManager ptm = asPlatformTransactionManager(tm);final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);if (txAttr == null || !(ptm instanceof CallbackPreferringPlatformTransactionManager)) {// 创建事务// 根据事务属性创建事务。如果当前方法需要事务，则开启一个新事务；否则，可能加入现有事务。TransactionInfo txInfo = createTransactionIfNecessary(ptm, txAttr, joinpointIdentification);Object retVal;try {//invocation.proceedWithInvocation()：实际执行目标方法。这是 AOP 拦截器链的一部分，确保在方法执行前后可以插入其他逻辑。retVal = invocation.proceedWithInvocation(); // 执行的是上面new CoroutinesInvocationCallback()里面的proceed方法！！！形成递归调用链！！！！！！！！}catch (Throwable ex) {//调用 completeTransactionAfterThrowing 方法，根据事务属性决定是否回滚事务。completeTransactionAfterThrowing(txInfo, ex);//见下面throw ex;}finally {//无论方法是否成功执行，都会清理当前线程的事务信息，确保不会影响后续操作。cleanupTransactionInfo(txInfo);}
........................// 如果方法成功执行且没有异常，则提交事务。commitTransactionAfterReturning(txInfo); //见下面return retVal;}
}

***retVal = invocation.proceedWithInvocation(); // 执行的是上面new CoroutinesInvocationCallback()里面的proceed方法！！！形成递归调用链！！！！！！！！***这一段我感觉挺重要的！！！

上面的代码结构有点儿熟悉哦，在这一小节最开始的时候，我们说了，如果我们要自定义实现这样的功能是不是和这个结构有点儿相似？

获取事务管理器
创建事务
try{执行我们service的方法 // ==============
} catch (异常 e) {回滚
} finally{清理当前线程的事务信息
}
提交事务

completeTransactionAfterThrowing(txInfo, ex); 出现异常，被捕获到了。

protected void completeTransactionAfterThrowing(@Nullable TransactionInfo txInfo, Throwable ex) {if (txInfo != null && txInfo.getTransactionStatus() != null) {......if (txInfo.transactionAttribute != null && txInfo.transactionAttribute.rollbackOn(ex)) {....// rollback吧txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());....}.......}
}

如果正常执行：commitTransactionAfterReturning(txInfo);

protected void commitTransactionAfterReturning(@Nullable TransactionInfo txInfo) {if (txInfo != null && txInfo.getTransactionStatus() != null) {// commit吧txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());}
}

小结一下！！

故如果在@Transactional方法里面，如果手动将抛出的异常给捕获了，

@Transactional
// 代码块test1方法-----start
public void test1() {try{mapper.insert()} catch ( Exception e ) {// 捕获了异常，没有继续往外抛log.info("asdsddsasdss");}
}
// 代码块test1方法-----end

那么，按照Spring源码的结构，就相当于这样的了

获取事务管理器
创建事务
try{// 代码块test1方法-----starttry{mapper.insert()} catch ( Exception e ) {// 捕获了异常，没有继续往外抛log.info("asdsddsasdss");}// 代码块test1方法-----end
} catch (异常 e) {回滚
} finally{清理当前线程的事务信息
}
提交事务

Spring捕获不到异常，就不会回滚了。

同类方法调用，如果最外层的没有加@Transactional注解，内层调用有的话，不生效

Spring 在启动时会扫描所有被 @Component、@Service、@Repository 等注解标记的类。如果类或方法上标注了 @Transactional 注解，Spring 会将这些方法标记为需要事务管理。

Spring 通过 TransactionAttributeSource 接口解析 @Transactional 注解中的属性（如传播行为、隔离级别、超时时间等）。

默认实现类是 AnnotationTransactionAttributeSource，它负责从 @Transactional 注解中提取事务属性。

各位还记得在上一小节SpringBoot事务自动配置里面吗，ProxyTransactionManagementConfiguration这个真正的配置类，他配置了一个Bean

new AnnotationTransactionAttributeSource();//AnnotationTransactionAttributeSource.java
@Override
public boolean isCandidateClass(Class<?> targetClass) {//遍历所有的 TransactionAnnotationParser，解析方法或类上的 @Transactional 注解。for (TransactionAnnotationParser parser : this.annotationParsers) {if (parser.isCandidateClass(targetClass)) {return true;}}return false;
}
//SpringTransactionAnnotationParser.java
public class SpringTransactionAnnotationParser implements TransactionAnnotationParser, Serializable {@Overridepublic boolean isCandidateClass(Class<?> targetClass) {return AnnotationUtils.isCandidateClass(targetClass, Transactional.class);}
}

BeanFactoryTransactionAttributeSourceAdvisor 是一个 AOP Advisor，它决定了哪些方法需要被事务拦截器拦截【见上一小节】

BeanFactoryTransactionAttributeSourceAdvisor 依赖于 TransactionAttributeSource 来解析方法或类上的 @Transactional 注解。内部使用了一个 TransactionAttributeSourcePointcut，它的 matches() 方法决定了哪些方法需要被拦截：

// BeanFactoryTransactionAttributeSourceAdvisor
public class BeanFactoryTransactionAttributeSourceAdvisor extends AbstractBeanFactoryPointcutAdvisor {@Nullableprivate TransactionAttributeSource transactionAttributeSource;private final TransactionAttributeSourcePointcut pointcut = new TransactionAttributeSourcePointcut() {@Override@Nullableprotected TransactionAttributeSource getTransactionAttributeSource() {return transactionAttributeSource;}};
}// TransactionAttributeSourcePointcut
private static final class TransactionAttributeSourcePointcut extends StaticMethodMatcherPointcut implements Serializable {@Overridepublic boolean matches(Method method, Class<?> targetClass) {TransactionAttributeSource tas = getTransactionAttributeSource();return (tas == null || tas.getTransactionAttribute(method, targetClass) != null);}
}

matches() 方法：

调用 TransactionAttributeSource 的 getTransactionAttribute() 方法，获取当前方法的事务属性。如果事务属性不为 null，则表示该方法需要被拦截；否则，不需要被拦截。

由于是同类方法之间的调用，故最外层没有@Transactional注解，拦截器链就不会有transactionInterceptor，所以就没有事务咯！

②编程式

@Resource
private TransactionTemplate transactionTemplate; // 需要这个。
// 5.编程式事务-1
@Override
public void saveSimple5(Account account) {Boolean execute = transactionTemplate.execute((status) -> {try {accountDao.insert(account);int i = 1 / 0;} catch (Exception e) {System.out.println("手动捕获异常~~~");status.setRollbackOnly(); // 回滚--手动控制return false;}return true;});System.out.println("execute = " + execute);
}

完全手动控制了。就不会有那种嵌套的问题了。但是每个流程都要考虑到哦

// UserServiceImpl.class
@Override
public void updateByUserId1(Integer uid) {transactionTemplate.execute((status)->{try {User user = userDao.selectById(uid);user.setName(user.getName() + "t");userDao.updateById(user);int i = 1 / 0; } catch (Exception e) {status.setRollbackOnly();}return null;});
}
// 6.编程式事务嵌套问题
// AccountServiceImpl.class
@Override
public void saveSimple6(Account account) {Boolean execute = transactionTemplate.execute((status) -> {try {accountDao.insert(account);// 调用了上面的方法userService.updateByUserId1(account.getUid());int i = 1 / 0; //=============这里【注释点1】} catch (Exception e) {System.out.println("手动捕获异常~~~");status.setRollbackOnly(); // 回滚--手动控制return false;}return true;});System.out.println("execute = " + execute);
}

上面的代码是不会往数据库插入和修改数据的。

思考题！！！！

如果上面的代码中，我将“【注释点1】”的那一行代码注释掉了，会发生什么呢？然后分析说，accountDao.insert(account);执行成功，userService.updateByUserId1(account.getUid()里面有异常手动回滚了，最外层没有异常，故account会插入一条记录，对于user的修改会回滚！。

那这样你就错了，事务默认的传播行为是REQUIRED，如果当前存在事务，则加入该事务；否则创建一个新事务。不管有几个事务存在，都**合并成一个事务来处理，只要有一个事务抛出异常，所有事务都会回滚；**案例6里面，编程式事务，默认情况下，TransactionTemplate 使用 PROPAGATION_REQUIRED传播机制，故二者合并成一个事务了。

也就是说saveSimple6这个方法里面的东西，都被包裹在一个事务里面了，最外层我们暂且称之为外部事务，但是在内部调用的updateByUserId1方法里面，内部事务已经抛出异常了，此时，整个事务已经被标记为rollback-only，最外层事务还commit的话，这就有问题了。会报错"Transaction rolled back because it has been marked as rollback-only"。

4.分布式事务

1.相关概念

分布式事务是指跨越多个分布式系统或服务的事务操作，需要保证这些操作要么全部成功，要么全部失败。在分布式系统中，由于数据和服务分散在不同的节点上，传统单机事务的 ACID 特性（原子性、一致性、隔离性、持久性）难以直接实现，因此需要引入分布式事务解决方案。

在单体应用中，事务通常由数据库管理系统（如 MySQL）直接支持，通过本地事务即可保证 ACID 特性。但在分布式系统中：

数据存储在不同的数据库或服务中。
服务之间通过网络通信，可能存在延迟、故障或分区。
无法直接使用本地事务来保证跨服务或跨数据库的一致性。

场景：

跨数据库事务：例如，订单服务需要同时更新订单数据库和库存数据库。
跨服务事务：例如，支付服务需要调用订单服务和库存服务，完成支付、更新订单状态和扣减库存。
跨系统事务：例如，银行转账需要同时更新两个不同银行的账户余额。

分布式事务的解决方案可以分为两类：

强一致性方案：保证事务的 ACID 特性，但性能较低。
最终一致性方案：通过异步补偿或消息队列实现最终一致性，性能较高。

2.解决方法

以下是常见的分布式事务解决方案：【来自于gpt】

（1）两阶段提交（2PC，Two-Phase Commit）

原理：
1. 准备阶段：协调者（Coordinator）询问所有参与者（Participant）是否可以提交事务。
2. 提交阶段：如果所有参与者都同意提交，协调者通知所有参与者提交事务；否则，通知所有参与者回滚事务。
优点：强一致性，保证事务的原子性。
缺点：
- 性能较低，同步阻塞。
- 协调者单点故障。
- 网络分区时可能导致数据不一致。

（2）三阶段提交（3PC，Three-Phase Commit）

原理：在 2PC 的基础上增加了一个预提交阶段，减少阻塞时间。
优点：比 2PC 更容错。
缺点：实现复杂，性能仍然较低。

（3）TCC（Try-Confirm-Cancel）

原理：
1. Try 阶段：尝试执行业务操作，预留资源。
2. Confirm 阶段：确认执行业务操作，提交资源。
3. Cancel 阶段：取消执行业务操作，释放资源。
优点：性能较高，适用于高并发场景。
缺点：需要业务代码实现 Try、Confirm、Cancel 逻辑，开发成本较高。