一.简介
Seata 是一款开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务。。可以用于解决分布式系统中的数据一致性问题。它是由阿里巴巴集团发起的开源项目,目前得到了广泛的应用和支持。
二.事务特性
事务就是用户定义的一系列数据库操作,这些操作可以视为一个完整的逻辑处理工作单元,要么全部执行,要么全部不执行,是不可分割的工作单元。事务有四大特性ACID:
(1) 原子性(Atomicity)
事务的原子性保证事务中包含的一组更新操作是原子的,中早期物理学中原子单位是最小的单位,不可分割。在事务中,我们将事务操作视为一个整体,执行过程中遵循“要么全部执行,要不都不执行”,不存在一半执行,一半未执行的情况。
(2)一致性(Consistency)
执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时,就代表数据库处于一致性状态。
如果数据库系统 运行中发生故障,有些事务尚未完成就被迫中断,这些未完成事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态,或者说是 不一致的状态。
(3)隔离性(Isolation)
事务的隔离性要求事务之间是彼此独立的,隔离的。及一个事务的执行不可以被其他事务干扰。具体到操作是指一个事务的操作必须在一个事务commit之后才可以进行操作。多事务并发执行时,相当于将并发事务变成串行事务,顺序执行。
(4)持续性(Durability)
指一个事物一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。
三.spring本地事务
在单体式架构中我们在同时执行两条紧密关联的数据库sql时,也就是满足原子性的两条sql时,比如增加订单和减少库存。这种事务我们称之为本地事务(Local Transaction)我们借助的是Spring内部的声明式事务,它是基于AOP的,在springboot中可以通过@Transactional注解的方式获得支持。
(1) 优点
1.提供了注解@Transactional,来进行事务管理, 添加上该注解,开启事务管理的机制无需编码, 自动处理, 简化了事务处理编程。
2.事务底层使用AOP解决了代码重复问题,将事务管理的关注点代码提取到切面中,在运行期动态的进行织入。
3.方法级别的事务回滚,合理划分方法的粒度可以做到符合各种业务场景的事务管理。
(2) 回滚规则
默认情况下,业务方法抛出运行时异常(RuntimeException),事务回滚。可以自定义回滚规则,通过属性rollbackFor和noRollBackFor来指定。
(3) 隔离级别
1.READ_UNCOMMITTED 读未提交, 不可以避免脏读, 幻读, 可重复读, 并发性好
2.READ_COMMITTED 读已提交, 最多使用, 不可以避免幻读, 可以避免重复读, 并发性能好
3.REPEATABLE_READ 可以重复读, 不可以避免幻读, 一定并发性能
4.SERIALIZABLE 序列化, 完全隔离, 不能并发, 性能不好
四.分布式事务
在微服务的项目中,业务逻辑层涉及远程调用,当前模块发生异常,无法操作远程服务器回滚
这时要想让远程调用也支持事务功能,就需要使用分布式事务组件Seata。保证微服务远程调用业务的原子性。
(1) 三个重要的角色
TC (Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
(2) 四种分布式事务解决方案
XA模式:强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入
TCC模式:最终一致的分阶段事务模式,有业务侵入
AT模式:最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式
SAGA模式:长事务模式,有业务侵入
1.XA模式
XA 规范是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范 提供了支持。
1.1.seata的XA模式
做了一些调整,但大体相似:
RM一阶段的工作:注册分支事务到TC,执行分支业务sql但不提交,报告执行状态到TC。
TC二阶段的工作:TC检测各分支事务执行状态,如果都成功,通知所有RM提交事务,如果有失败,通知所有RM回滚事务。
RM二阶段的工作:接收TC指令,提交或回滚事务。
2.AT模式
AT模式同样是分阶段提交的事务模型,不过缺弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作:注册分支事务,记录undo-log(数据快照),执行业务sql并提交,报告事务状态。
阶段二提交时RM的工作:删除undo-log即可,阶段二回滚时RM的工作:,根据undo-log恢复数据到更新前。
3.TCC模式
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:
Try:资源的检测和预留。
Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功。
Cancel:预留资源释放,可以理解为try的反向操作。
3.1.TCC的空回滚和业务悬挂
当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚,就是空回滚。
对于已经空回滚的业务,如果以后继续执行try,就永远不可能confirm或cancel,这就是业务悬挂。应当阻止执行空回滚后的try操作,避免悬挂。
4.Saga模式
Saga模式是SEATA提供的长事务解决方案。也分为两个阶段:
一阶段:直接提交本地事务
二阶段:成功则什么都不做;失败则通过编写补偿业务来回滚
4.1.Saga模式优点
1.事务参与者可以基于事件驱动实现异步调用,吞吐高
2.一阶段直接提交事务,无锁,性能好
3.不用编写TCC中的三个阶段,实现简单
4.2.Saga模式缺点
软状态持续时间不确定,时效性差,没有锁,没有事务隔离,会有脏写