spring的事务管理——seata的整合

最新推荐文章于 2025-04-27 13:30:09 发布

玛朵布莎.哈

最新推荐文章于 2025-04-27 13:30:09 发布

阅读量1.4k

点赞数 26

文章标签： java spring mybatis

本文链接：https://blog.youkuaiyun.com/weixin_63588450/article/details/136499106

版权

事务

事务是由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。

事务四个典型特性，即ACID，原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

原子性：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部都执行，要么都不执行。
一致性：指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
隔离性：多个事务并发访问时，事务之间是相互隔离的，一个事务不应该被其他事务干扰，多个并发事务之间要相互隔离。。
持久性：表示事务完成提交后，该事务对数据库所作的操作更改，将持久地保存在数据库之中

MySQL的rollback思想

mysql定义了两张表undo log和redo log其中undo log是记录数据被修改前的信息以及新增和删除的数据信息，当事务需要回滚时会根据undo log里面记录的信息生成对应的sql语句进行回滚。如：

如果在回滚日志里有新增数据记录，则生成删除该条的语句；
如果在回滚日志里有删除数据记录，则生成生成该条的语句；
如果在回滚日志里有修改数据记录，则生成修改到原先数据的语句。

redo log主要是记录用户操作提交的数据日志，用于数据的数据的持久化。redo log持久化到磁盘中，当系统重启后会读取redo log恢复数据。
事务的原子性是通过 undo log 来实现的
事务的持久性性是通过 redo log 来实现的

spring事务

spring对事务的支持主要是通过操作数据库对事务进行操作。没有数据库的事务支持，spring无法提供事务的功能。而对于纯jdbc操作数据库的事务，有以下方法：

    1. 获取连接 Connection con = DriverManager.getConnection()
    2. 开启事务con.setAutoCommit(true/false);
    3. 执行CRUD
    4. 提交事务/回滚事务 con.commit() / con.rollback();
    5. 关闭连接 conn.close();

spring可以通过@Transactional注解进行事务管理，让我们不用书写2和4的代码。@Transactional主要是通过aop和ioc技术来完成实现的。同时注意@Transactional不生效的三种情况：

@Transactional注解标注方法修饰符为非public时不生效。@Transactional是基于动态代理实现的，@Transactional注解实现原理中分析了实现方法，在bean初始化过程中，对含有@Transactional标注的bean实例创建代理对象，这里就存在一个spring扫描@Transactional注解信息的过程，不幸的是源码中体现，标注@Transactional的方法如果修饰符不是public，那么就默认方法的@Transactional信息为空，那么将不会对bean进行代理对象创建或者不会对方法进行代理调用
在类内部调用调用类内部@Transactional标注的方法时不生效。事务管理是基于动态代理对象的代理逻辑实现的，那么如果在类内部调用类内部的事务方法，这个调用事务方法的过程并不是通过代理对象来调用的，而是直接通过this对象来调用方法，不存在代理对象。
try catch中捕获了异常却没将异常抛出（或者抛出的异常不属于@Transactional的捕获异常范围）

参考文章：【spring 】spring 的事务(transaction、事务的传播属性、隔离级别) 一基础概念介绍_transactiondefinition 默认事务传播类型-优快云博客

spring事务的传播属性

什么是事务的传播行为呢？

就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。

例如：两个事务方法，一个A方法，一个B方法。在这两个方法上都添加了@Transactional注解，就代表这两个方法都具有事务，而在A方法当中又去调用了B方法。

所谓事务的传播行为，指的就是在A方法运行的时候，首先会开启一个事务，在A方法当中又调用了B方法， B方法自身也具有事务，那么B方法在运行的时候，到底是加入到A方法的事务当中来，还是B方法在运行的时候新建一个事务？这个就涉及到了事务的传播行为。

我们要想控制事务的传播行为，在@Transactional注解的后面指定一个属性propagation，通过 propagation 属性来指定传播行为。接下来我们就来介绍一下常见的事务传播行为。

属性值	含义
REQUIRED	【默认值】需要事务，有则加入，无则创建新事务
REQUIRES_NEW	需要新事务，无论有无，总是创建新事务
SUPPORTS	支持事务，有则加入，无则在无事务状态中运行
NOT_SUPPORTED	不支持事务，在无事务状态下运行,如果当前存在已有事务,则挂起当前事务
MANDATORY	必须有事务，否则抛异常
NEVER	必须没事务，否则抛异常
NESTED	嵌套事务

嵌套事务呈现父子事务概念，二者之间是有关联的，核心思想就是子事务不会独立提交，而是取决于父事务，当父事务提交，那么子事务才会随之提交；如果父事务回滚，那么子事务也回滚。

与此相反，PROPAGATION_REQUIRES_NEW的内层事务，会立即提交，与外层毫无关联。

但是子事务又有自己的特性，那就是可以独立进行回滚，不会引发父事务整体的回滚(当然需要try catch子事务，避免异常传递至父层事务，如果没有，则也会引发父事务整体回滚)。这个特性比较有意思，虽然不能独立提交，但是可以独立回滚，因此，如果存在ABC 三个子事务，那么每个子事务都可以独立回滚，子事务类似一个游戏中的保存点，假设某个时间点，创建了一个保存点A，角色有10发子弹，主线继续发生时，对应执行某个子事务内的逻辑，如果游戏角色打了4发子弹，剩余6发子弹时挂了，点击返回上一个保存点，可以重新玩一次，此时该角色又是10发子弹，对应的就是子事务发生异常，子事务回滚到事务执行之前的那个点，放佛从来没有执行过该子事务一样，数据库的数据也不会发生变更。更重要的是，游戏角色仅会返回到某个进度的保存点，而不是返回到游戏的开始点，否则进度丢了，都想骂人了。

子事务可以独立回滚，也可以通过传递异常，让父事务也回滚，根源在于用户策略，在父事务通过try catch 对子事务进行包裹，灵活策略；

该传播机制的特点是可以保存状态保存点，当前事务回滚到某一个点，从而避免所有的嵌套事务都回滚，即各自回滚各自的，如果子事务没有把异常吃掉，基本还是会引起全部回滚的

原文链接：【spring】spring 的事务(transaction) 四嵌套事务PROPAGATION_NESTED-优快云博客

分布式事务

分布式事务就是指不是在单个服务或单个数据库架构下，产生的事务，例如：跨数据源的分布式事务，跨服务的分布式事务。

CAP定理：

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

CAP定理的矛盾：

· 在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。

当节点接收到新的数据变更时，就会出现问题了：

如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。

如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。

也就是说，在P一定会出现的情况下，A和C之间只能实现一个。

BASE理论:

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

解决分布式事务思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

这里的子事务是指子系统事务又称分支事务，有关联的各个子事务在一起称为全局事务。

Seata的架构

Seata事务管理中有三个重要的角色：

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。