Spring 家族主流分布式事务组件

Spring 家族主流分布式事务组件大揭秘

Spring 家族主流分布式事务组件大全（按常用程度排序）

一、阿里系 Spring Cloud Alibaba 生态（最常用）

1. Seata

目前微服务首选

• 支持模式：AT、TCC、SAGA、XA
• 特点：无侵入、轻量、适配所有 SpringBoot/Cloud，兼容 MySQL、Oracle
• 适用：绝大多数业务微服务跨服务、跨库事务

2. GTS（阿里旧版）

• 阿里早期分布式事务中间件，现在基本被 Seata 替代，新项目不用

---

二、Spring 官方 / 传统经典方案

3. Spring Transaction + JTA + XA

• 是 Spring 原生支持的 XA 强一致性事务
• 依赖：Atomikos、Bitronix、Jboss Transactions
• 原理：标准 2PC，数据库层面强一致
• 缺点：性能差、阻塞高、不适合高并发微服务，只适合传统老项目

4. Spring Cloud Task / Spring Batch

不算严格分布式事务，只做任务批次补偿、任务状态一致性，适合定时任务、批处理场景

---

三、TCC 框架类（Spring 可集成）

5. TCC-Transaction（开源经典）

• 独立 TCC 框架，完美适配 Spring
• 手动写 Try/Confirm/Cancel 三个方法
• 适合：不能用 AT 模式、非关系型数据库、特殊业务

6. ByteTCC

轻量级 TCC 框架，注解式开发，Spring 无缝整合

---

四、可靠消息最终一致性（业界通用方案，Spring 生态标配）

不算中间件组件，是架构方案，Spring 项目必用：

1. 本地消息表
2. 事务消息（RocketMQ）

• RocketMQ 事务消息是 Spring Cloud 标配，最终一致性
• 适合：高并发、允许短暂不一致、最终要一致的场景（下单、扣库存、通知）

---

五、其他小众组件

• Hmily：高性能 TCC/SAGA 分布式事务框架，适配 SpringBoot/Cloud
• MyCAT 分布式事务：偏数据库中间件层面，配合 Spring 使用

---

选型一句话总结

1. 新项目微服务 → 直接用 Seata AT
2. 高并发、可最终一致 → RocketMQ 事务消息
3. 特殊业务 / 非 MySQL → Seata TCC 或 Hmily、TCC-Transaction
4. 老旧项目强一致、不在乎性能 → Spring JTA+XA(Atomikos)
5. 老 GTS 项目 → 逐步迁移到 Seata

需要我给你做一张各组件优缺点、适用场景对比表，方便你面试和技术选型吗？

 

 

 

 

Spring生态分布式事务组件 对比表（面试+选型直接背）

组件 / 方案	核心模式	侵入性	性能	一致性	开发难度	适用场景	缺点
Seata AT	2PC 补偿	极低（仅加注解）	高	弱一致（最终一致）	极低	90% 微服务跨库、跨服务常规业务	只适配关系型数据库；隔离级别略低
Seata TCC	手动 TCC	高	中	强一致	高	非关系库、特殊业务、AT 不支持场景	需手动写 Try/Confirm/Cancel，代码量大
Seata SAGA	长事务补偿	中	中	最终一致	中	长流程业务、订单履约、流程编排	回滚逻辑需自己定义
Seata XA	标准 XA-2PC	低	低	强一致	低	金融核心、绝对不能脏数据、低并发	性能差、全局锁、高并发卡死
Spring JTA+Atomikos	标准 XA	低	低	强一致	中	传统老项目、多数据源本地事务	笨重、性能差、微服务不推荐
RocketMQ 事务消息	可靠消息最终一致	低	极高	最终一致	中	高并发下单、积分、通知、异步业务	不适合强实时强一致场景
TCC-Transaction	经典 TCC	高	中	强一致	高	自研 TCC、不想依赖 Seata	规范繁琐、维护成本高
Hmily	TCC/SAGA	中	高	最终 / 强一致	中	高性能分布式补偿、开源替代 Seata	生态不如 Seata 成熟

一、快速选型口诀

1. 普通微服务、不想写多余代码 → 无脑 Seata AT
2. 高并发、能接受短暂不一致 → RocketMQ 事务消息
3. 金融核心、必须强一致、低并发 → Seata XA / JTA XA
4. 特殊业务、Redis / 非关系库 → Seata TCC / Hmily
5. 长流程业务、链路特别长 → Seata SAGA

二、面试必背区别

1. AT 不用改业务 SQL，自动生成 undo 日志补偿；TCC 要自己实现三个接口。
2. XA 是数据库原生 2PC，强一致但性能拉胯；AT 是业务层模拟 2PC，性能高。
3. Seata 是现在 SpringCloudAlibaba 官方标配，其他都是替代或老旧方案。
4. 可靠消息（RocketMQ）不属于分布式事务框架，是架构设计方案，高并发首选。

三、分布式事务4大模式 极简面试口述版（直接背诵）

1. Seata AT（最常用）

AT 属于柔性事务、补偿型 2PC，也是企业微服务首选。一阶段执行业务 SQL，Seata 拦截数据库操作，自动记录回滚 Undo 日志并提交本地事务，快速释放数据库锁，并发性能高。二阶段如果全局事务成功，就异步删除 Undo 日志；如果出现异常，就通过 Undo 日志反向执行 SQL，自动回滚所有分支事务。最大优势是零代码侵入，只需添加注解，不用改动业务逻辑，缺点是仅支持关系型数据库，存在少量幻读、脏读问题，隔离级别较低。

2. Seata TCC

TCC 是手动实现的硬事务，完全不依赖数据库事务，适配所有数据源，包括 Redis、第三方接口等。分为三个自定义方法：Try 阶段完成资源校验、资源预留；Confirm 阶段确认执行业务提交；Cancel 阶段回滚释放预留资源。一阶段锁定资源，二阶段根据全局事务状态执行确认或取消。优点是一致性可控、适配场景广，缺点是代码侵入性极强，每个业务都要手动编写三套代码，开发和维护成本极高。

3. Seata XA

XA 是数据库原生标准 2PC 事务，属于刚性事务。一阶段所有分支数据库完成资源预提交、资源锁定，不真正提交；等待事务协调器通知后，二阶段统一执行全局提交或全局回滚。它依托数据库原生能力，一致性最强、几乎无数据偏差，代码侵入极低。但致命缺点是阻塞严重、性能极差，一阶段锁定资源后会持续占用数据库锁，直到二阶段执行完毕，极其不适合高并发业务，仅用于金融、支付等低并发、强数据一致的核心场景。

4. Seata SAGA

SAGA 专门适配长链路、长耗时分布式事务，属于最终一致性方案。整体思路是正向执行每一个分支业务，同时为每个业务节点配置对应的反向补偿业务。事务执行过程中，如果某一个节点失败，就逆序执行前面所有成功节点的补偿逻辑，完成整体事务回滚。它无需锁定资源、并发性能较好，适合订单履约、物流流程、工单审批等长流程业务。缺点是无事务隔离，容易出现数据脏写，且所有补偿逻辑需要开发人员手动编写。

四、面试高频总结追问

1. AT 和 XA 的核心区别？ XA 是数据库层原生2PC，锁粒度大、阻塞久、性能差；AT 是框架层模拟2PC，一阶段直接提交本地事务、释放锁，性能远超XA，是工程最优解。

2. AT 和 TCC 的核心区别？ AT 自动生成日志补偿，零侵入；TCC 全手动代码补偿，适配非数据库场景。

3. SAGA 适合什么场景？ 只用于长流程、异步编排、耗时久的业务，不适合高一致性、高并发短事务。