Seata分布式事务原理
发布于2021-11-21 21:15 阅读(902) 评论(0) 点赞(17) 收藏(4)
1.初始Seata
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。
2.Seata 的架构
三个重要的角色：
TC (Transaction Coordinator)：
- 事务协调者： 维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager)：
- 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager)：
- 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
3. 四种事务模式
XA模式： 强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式： 最终一致的分阶段事务模式，有业务侵入
AT模式： 最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式： 长事务模式，有业务侵入
3.1 XA模式
RM一阶段的工作：
- 注册事务到TC
- 执行分支业务sql但不提交
- 报告执行状态到TC
TC二阶段的工作：
1.检测各分支事务的执行状态
2.如果都成功，通知所有RM提交事务
3.如果有失败，通知所有RM回滚事务
RM接收TC指令，提交或回滚事务
XA模式的优点：
事务的强一致性，满足ACID原则。
常用数据库都支持，实现简单，并且没有代码侵入
缺点：
因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务
3.2 AT模式
优点：
一阶段完成直接提交事务，释放数据库资源，性能比较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交
缺点：
两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多
3.3 TCC模式
Try：资源的检测和预留；。
Confirm：完成资源操作业务，要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。
TCC工作原理图：
优点：
一阶段完成直接提交事务，释放数据库资源，性能好
相比AT模型，无需生成快照，无需使用全局锁，性能最强
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
缺点：
有代码侵入，需要人为编写try, Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理
3.4 SAGA模式
Saga模式是 Seata 提供的长事务解决方案。
分为两个阶段：
一阶段：直接提交本地事务
二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
优点：
事务参与者可以基于事件驱动实现异步调用，吞吐高
一阶段直接提交事务，无锁，性能好
不用编写TCC中的三个阶段，实现简单
缺点：
软状态持续时间不确定，时效性差
没有锁，没有事务隔离，会有脏写
4. 总结
原文链接:https://blog.csdn.net/m0_60491538/article/details/121405252
所属网站分类: 技术文章 > 博客
作者：忽明忽灭
链接：http://www.javaheidong.com/blog/article/326642/8e36bc23c3354a060dd1/
来源：java黑洞网
任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任
昵称:
评论内容：(最多支持255个字符)
---无人问津也好，技不如人也罢，你都要试着安静下来，去做自己该做的事，而不是让内心的烦躁、焦虑，坏掉你本来就不多的热情和定力