分布式事务之Seata

原创

已于 2025-10-07 20:15:36 修改 · 1.1k 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#java #分布式

于 2025-05-23 12:51:56 首次发布

概述

Seata有四种模式

AT模式：无侵入式的分布式事务解决方案，适合不希望对业务进行改造的场景，但由于需要添加全局事务锁，对影响高并发系统的性能。该模式主要关注多DB访问的数据一致性，也包括多服务下的多DB数据访问一致性问题。通过更新前快照回滚、更新后快照对比在二阶段提交时是否有人修改（为不受Seata代理的数据源做兜底），解决脏写。

优点：

一阶段完成直接提交事务，释放数据库资源，性能比较好

利用全局锁实现读写隔离

没有代码侵入，框架自动完成回滚和提交

缺点：

两阶段之间属于软状态，属于最终一致

框架的快照功能会影响性能，但比XA模式要好很多

TCC模式：高性能的分布式事务解决方案，适用于对性能要求比较高的场景。该模式主要关注业务拆分，在按照业务横向扩展资源时，解决服务间调用的一致性问题。

优点：

一阶段完成直接提交事务，释放数据库资源，性能好

相比AT模型，无需生成快照，无需使用全局锁，性能最强

不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

Redis这种也可以使用TCC模式

缺点：

有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦

软状态，事务是最终一致

需要考虑Confirm和Cancel的失败情况，做好幂等处理

因为如果失败Seata会重试，所有要做好幂等

Saga模式：长事务的分布式事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统。Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统，事务参与者可以是其它公司的服务也可以是遗留系统的服务，并且对于无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。

优点：

一阶段提交本地数据库事务，无锁，高性能；

参与者可以采用事务驱动异步执行，高吞吐；

补偿服务即正向服务的“反向”，易于理解，易于实现；

缺点：

Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。后续会讲到对于缺乏隔离性的应对措施。

XA模式：强一致性。XA早期版本是一种规范主流数据库对XA规范提供了支持，没有TM（事务管理者的概念）只有TC和RM。一阶段不提交事务，在第二阶段TM发起事务提交/回滚时才会让TC检查分支状态做提交/回滚因此是强一致性的

优点：

强一致性

易于使用：因为主流数据库都支持且无代码侵入

缺点：

第一阶段不提交，在等待过程中占用数据库锁，占用系统资源，性能差

Seata核心组件

TC（Transaction Coordinator）：全局事务协调器，负责管理全局事务的状态。

TM（Transaction Manager）：事务管理器，负责发起全局事务，并向TC注册事务。

RM（Resource Manager）：资源管理器，负责管理资源的本地事务，并向TC汇报事务状态。