Seata

最新推荐文章于 2025-07-22 15:16:10 发布

原创最新推荐文章于 2025-07-22 15:16:10 发布 · 963 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #微服务 #seata #分布式事务

SpringCloud Alibaba学习之旅专栏收录该内容

4 篇文章

订阅专栏

一、基本理论

1.分布式事务：

在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致；

2.CAP定理：

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

分布式系统无法同时满足这三个指标，即CAP定理；

3.BASE理论：

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

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

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致；

CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致，但事务等待过程中，处于弱可用状态（等待资源）；

二、Seata架构

1.三个角色

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

2.XA模式

RM一阶段：

注册分支事务到TC；

执行分支业务sql但不提交；

报告执行状态到TC；

TC二阶段：

检测各分支事务执行状态“

如果都成功，通知所有RM提交事务；

如果有失败，通知所有RM回滚事务；

RM二阶段：

接收TC指令，提交或回滚事务；

优点：

事务的强一致性，满足ACID原则；

常用数据库都支持，实现简单，并且没有代码倾入；

缺点：

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差；

依赖关系型数据库实现事务；

3.AT模式

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

阶段一RM的工作：

注册分支事务；

记录undo-log（数据快照）；

执行业务sql并提交；

报告事务状态；

阶段二提交时RM的工作：

删除undo-log即可；

阶段二回滚时RM的工作：

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

优点：

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

缺点：

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

AT与XA的区别：

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源；

XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚；

XA模式强一致；AT模式最终一致；

4.TCC模式

Try：资源检查和预留；
Confirm：业务执行和提交；
Cancel：预留资源的释放；

优点：

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

缺点：

有代码入侵，需编写try、confirm、cancel接口；
软状态，事务最终一致；
需要考虑confirm和cancel的失败情况；

空回滚：

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作，在未来执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

业务悬挂：

对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂，应当阻止执行空回滚后的try操作，避免悬挂。

5.Saga模式

Saga模式是seata提供的长事务解决方案：

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

优点：

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

缺点：

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

6.四种模式对比

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