分布式事务--Seata

简介: 分布式事务--Seata

分布式事务–Seata

Seata是分布式事务解决方案。致力于提供高性能简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。官网地址:http://seata.io/,其中的文档、播客中提供了大量的使用说明、源码分析。

一、事务的ACID原则

分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。

原子性 事务中的所有操作,要么全部成功,要么全部失败
一致性 要保证数据库内部完整性约束、声明性约束
隔离性 对同一资源操作的事务不能同时发生
持久性 对数据库做的一切修改将永久保存,不管是否出现故障

二、CAP定理

分布式系统节点通过网络连接,一定会出现分区问题(P);当分区出现时,系统的一致性(C)和可用性(A)就无法同时满足。

分布式系统有三个指标:

  • Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
  • Availability(可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
  • Partition tolerance (分区容错性
  • Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
  • Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务。

三、BASE理论

1.BASE理论是对CAP的一种解决思路,包含三个思想:

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

2.分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论:

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

四、分布式事务模型

解决分布式事务,各个子系统之间必须能感知到彼此的事务状态,才能保证状态一致,因此需要一个事务协调者来协调每一个事务的参与者(子系统事务)。

1.解决分布式事务的模型

  • 分支事务:子系统事务;分布式事务中包含的每个子系统的事务。
  • 全局事务:有关联的各个分支事务的集合;整个分布式事务。

2.解决分布式事务的思想

  • 最终一致思想:各分支事务分别执行并提交,如果有不一致的情况,再想办法恢复数据。
  • 强一致思想:各分支事务执行完业务不要提交,等待彼此结果。而后统一提交或回滚。

五、Seata架构

1.Seata事务管理中有三个重要的角色:

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

2.Seata提供了四种不同的分布式事务解决方案:

  • XA模式:强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入。
  • TCC模式:最终一致的分阶段事务模式,有业务侵入。
  • AT模式:最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式。
  • SAGA模式:长事务模式,有业务侵入。

3.nacos服务名称组成包括?

namespace(命名空间) + group(分组名称) + serviceName(服务名称) + cluster(区域)。

4.seata客户端获取tc的cluster名称方式?

tx-group-service值为keyvgroupMapping中查找。

六、XA模式原理

XA 规范是 X/Open 组织定义的分布式事务处理(DTP)标准,XA 规范描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范提供了支持。

6.1 seata的XA模式

RM一阶段的工作:

  1. 注册分支事务到TC
  2. 执行分支业务sql但不提交
  3. 报告执行状态到TC

TC二阶段的工作:

  • TC检测各分支事务执行状态
  • 如果都成功,通知所有RM提交事务
  • 如果有失败,通知所有RM回滚事务

RM二阶段的工作:

  • 接收TC指令,提交或回滚事务

6.2 seata的XA的优缺点

XA模式的优点

  • 事务的强一致性,满足ACID原则
  • 常用数据库都支持,实现简单,并且没有代码侵入

XA模式的缺点

  • 因为一阶段需要锁定数据库资源,等待二阶段结束才释放,性能较差
  • 依赖关系型数据库实现事务

6.3 实现XA模式

Seata的starter已经完成了XA模式的自动装配,实现非常简单,步骤如下:

  1. 修改application.yml文件(每个参与事务的微服务),开启XA模式。
  2. 给发起全局事务的入口方法添加@GlobalTransactional注解。
  3. 重启服务并测试。

七、AT模式原理

AT模式同样是分阶段提交的事务模型,不过缺弥补了XA模型中资源锁定周期过长的缺陷。

阶段一RM的工作:

  1. 注册分支事务
  2. 记录undo-log(数据快照)
  3. 执行业务sql并提交
  4. 报告事务状态

阶段二提交时RM的工作:

  • 删除undo-log

阶段二回滚时RM的工作:

  • 根据undo-log恢复数据到更新前

AT模式与XA模式最大的区别

  • XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
  • XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚。
  • XA模式强一致;AT模式最终一致

7.1 AT模式的脏写问题

在并发的情况下,事务一执行RM第一阶段

  • 1.1.获取DB锁,保存快照
  • 1.2.执行业务
  • 1.3.提交事务,释放DB锁

这时DB锁释放,事务二得到DB锁,执行RM第一阶段

  • 1.1.获取DB锁,保存快照
  • 1.2.执行业务
  • 1.3.提交事务,释放DB锁

后面被事务一获取DB锁,根据快照恢复数据,这时将快照恢复,导致事务二的操作白干了,造成数据安全性问题,隔离性没有得到保障。

7.2 AT模式的写隔离

全局锁:由TC记录当前正在操作某行数据的事务,该事务持有全局锁,具备执行权。

在并发的情况下,事务一执行RM第一阶段

  • 1.1.获取DB锁(数据库锁),保存快照
  • 1.2.执行业务
  • 此时获取全局锁
  • 1.3.提交事务,释放DB锁

这时DB锁释放,事务二得到DB锁,执行RM第一阶段

  • 1.1.获取DB锁,保存快照
  • 1.2.执行业务
  • 此时获取全局锁,但由于事务一已经获取重试,默认30次,
    间隔10毫秒
  • 1.4.任务超时,回滚并释放DB锁

而这时事务一

  • 等待DB锁
  • 2.1.获取DB锁,根据快照恢复数据
  • 释放全局锁

由于DB锁的等待时间比全局锁久,所以事务一可以等待事务二任务超时,回滚并释放DB锁,但还是有局限,全局锁只能共同作用于seata的事务,不是seata的管理全局事务也可以修改seata的字段。

解决办法

  • 1.1.事务一获取DB锁,保存快照 --> before-imag
  • 1.2.事务一执行业务s --> after-image(执行完后再生成一个快照)
  • 在这种极端的情况下,非seata的管理全局事务修改seata的字段,提交事务,释放DB锁
  • 这时事务一在2.1.获取DB锁,根据快照恢复数据,对比一下此时数据库的字段数据是否被修改过,与 after-image 进行比较即可,再释放全局锁。
  • 2.2.记录异常,发送警告,人工介入

7.3 AT模式的优缺点

AT模式的优点

  • 一阶段完成直接提交事务,释放数据库资源,性能比较好
  • 利用全局锁实现读写隔离
  • 没有代码侵入,框架自动完成回滚和提交

AT模式的缺点

  • 两阶段之间属于软状态,属于最终一致
  • 框架的快照功能会影响性能,但比XA模式要好很多

八、TCC模式原理

TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:

  • Try:资源的检测和预留
  • Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功
  • Cancel:预留资源释放,可以理解为try的反向操作

8.1 TCC模式举例

一个扣减用户余额的业务。假设账户A原来余额是100,需要余额扣减30元。

  • 阶段一( Try ):检查余额是否充足,如果充足则冻结金额增加30元,可用余额扣除30
  • 阶段二:假如要提交(Confirm),则冻结金额扣减30
  • 阶段二:如果要回滚(Cancel),则冻结金额扣减30,可用余额增加30

8.2 TCC模式优缺点

TCC的优点

  • 一阶段完成直接提交事务,释放数据库资源,性能好
  • 相比AT模型,无需生成快照,无需使用全局锁,性能最强
  • 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库

TCC的缺点

  • 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦
  • 软状态,事务是最终一致
  • 需要考虑Confirm和Cancel的失败情况,做好幂等处理

8.3 TCC的空回滚和业务悬挂

  • 空回滚:当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚。
  • 业务悬挂:对于已经空回滚的业务,如果以后继续执行try,就永远不可能confirm或cancel。
  • 应当阻止执行空回滚后的try操作,避免悬挂,执行try操作需要先判断是否发生过回滚,发生过则结束;执行cancel操作也要先判断try操作是否已经执行过。

ps: TCC模式和AT模式类似,yml文件中不需要修改数据源代理的AT模式,只需要编写实现三个方法即可实现TCC模式。

九、Saga模式

Saga模式是SEATA提供的长事务解决方案。也分为两个阶段:

  • 一阶段:直接提交本地事务
  • 二阶段:成功则什么都不做;失败则通过编写补偿业务来回滚

9.1 Saga模式优缺点

Saga模式优点

  • 事务参与者可以基于事件驱动实现异步调用,吞吐高
  • 一阶段直接提交事务,无锁,性能好
  • 不用编写TCC中的三个阶段,实现简单

Saga模式缺点

  • 软状态持续时间不确定,时效性差
  • 没有锁,没有事务隔离,会有脏写

十、四种模式对比

XA AT TCC SAGA
一致性 强一致 弱一致 弱一致 最终一致
隔离性 完全隔离 基于全局锁隔离 基于资源预留隔离 无隔离
代码侵入 有,要编写三个接口 有,要编写状态机和补偿业务
性能 非常好 非常好
场景 对一致性、隔离性有高要求的业务 基于关系型数据库的大多数分布式事务场景都可以 对性能要求较高的事务。有非关系型数据库要参与的事务。 业务流程长、业务流程多参与者包含其它公司或遗留系统服务,无法提供 TCC 模式要求的三个接口

->微服务技术栈高级篇--分布式事务--Seata课程视频

高级篇Day2-01-分布式事务理论基础_哔哩哔哩_bilibili

<-

记录每一个学习瞬间

目录
相关文章
|
1月前
|
Java 数据库
在Java中使用Seata框架实现分布式事务的详细步骤
通过以上步骤,利用 Seata 框架可以实现较为简单的分布式事务处理。在实际应用中,还需要根据具体业务需求进行更详细的配置和处理。同时,要注意处理各种异常情况,以确保分布式事务的正确执行。
|
18天前
|
消息中间件 SQL 中间件
大厂都在用的分布式事务方案,Seata+RocketMQ带你打破10万QPS瓶颈
分布式事务涉及跨多个数据库或服务的操作,确保数据一致性。本地事务通过数据库直接支持ACID特性,而分布式事务则需解决跨服务协调难、高并发压力及性能与一致性权衡等问题。常见的解决方案包括两阶段提交(2PC)、Seata提供的AT和TCC模式、以及基于消息队列的最终一致性方案。这些方法各有优劣,适用于不同业务场景,选择合适的方案需综合考虑业务需求、系统规模和技术团队能力。
133 7
|
1月前
|
存储 Java 关系型数据库
在Spring Boot中整合Seata框架实现分布式事务
可以在 Spring Boot 中成功整合 Seata 框架,实现分布式事务的管理和处理。在实际应用中,还需要根据具体的业务需求和技术架构进行进一步的优化和调整。同时,要注意处理各种可能出现的问题,以保障分布式事务的顺利执行。
54 6
|
1月前
|
数据库
如何在Seata框架中配置分布式事务的隔离级别?
总的来说,配置分布式事务的隔离级别是实现分布式事务管理的重要环节之一,需要认真对待和仔细调整,以满足业务的需求和性能要求。你还可以进一步深入研究和实践 Seata 框架的配置和使用,以更好地应对各种分布式事务场景的挑战。
32 6
|
29天前
|
消息中间件 运维 数据库
Seata框架和其他分布式事务框架有什么区别
Seata框架和其他分布式事务框架有什么区别
28 1
|
3月前
|
SQL NoSQL 数据库
SpringCloud基础6——分布式事务,Seata
分布式事务、ACID原则、CAP定理、Seata、Seata的四种分布式方案:XA、AT、TCC、SAGA模式
SpringCloud基础6——分布式事务,Seata
|
4月前
|
关系型数据库 MySQL 数据库
SpringCloud2023中使用Seata解决分布式事务
对于分布式系统而言,需要保证分布式系统中的数据一致性,保证数据在子系统中始终保持一致,避免业务出现问题。分布式系统中对数据的操作要么一起成功,要么一起失败,必须是一个整体性的事务。Seata简化了这个使用过程。
100 2
|
4月前
|
Java 关系型数据库 MySQL
(二十七)舞动手指速写一个Seata-XA框架解决棘手的分布式事务问题
相信大家对于事务问题都不陌生,在之前《MySQL事务篇》中曾详解过MySQL的事务机制,在传统的单库环境下开发,咱们可依赖于MySQL所提供的事务机制,来确保单个事务内的一组操作,要么全部执行成功,要么全部执行失败。
|
4月前
|
Java Nacos Docker
"揭秘!Docker部署Seata遇上Nacos,注册成功却报错?这些坑你不得不防!一网打尽解决秘籍,让你的分布式事务稳如老狗!"
【8月更文挑战第15天】在微服务架构中,Nacos搭配Seata确保数据一致性时,Docker部署Seata后可能出现客户端连接错误,如“can not connect to services-server”。此问题多由网络配置不当、配置文件错误或版本不兼容引起。解决策略包括:调整Docker网络设置确保可达性;检查并修正`file.conf`和`registry.conf`中的Nacos地址和端口;验证Seata与Nacos版本兼容性;修改配置后重启服务;参考官方文档和最佳实践进行配置。通过这些步骤,能有效排除故障,保障服务稳定运行。
359 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?