一、是否需要分布式事务
什么时候需要分布式事务？
分布式事务的使用场景，本质上是由业务操作跨越了多个独立的资源（数据库/服务） ，且业务要求这些操作必须保持一致所驱动的。
只要满足以下两个条件，就需要考虑分布式事务：
-
操作跨多个资源：比如操作了多个数据库，或调用了多个服务，每个服务有自己的数据库。
-
要求数据一致：这些操作要么全部成功，要么全部失败，不能出现"订单创建了但库存没扣"这种中间状态。
什么时候不需要分布式事务？
以下场景通常不需要引入分布式事务：
• 操作只在单个数据库内：用本地事务（@Transactional）即可。
• 业务允许最终一致且不要求回滚：比如发短信通知、写日志，失败重试即可。
• 对实时性要求极低：比如 T+1 对账，用定时任务补偿即可。
• 业务本身能容忍中间状态：比如社交点赞、浏览记录。
二、先判断业务场景的特征，再根据特征匹配最合适的技术方案。
📊 场景 + 选型决策表
| 业务场景 | 典型特征 | 一致性要求 | 推荐方案 | 理由 |
|---|---|---|---|---|
| 电商下单（创建订单+扣库存+扣余额） | 短事务、并发中等、步骤少（3-5个） | 最终一致 | Seata AT 模式 | 无侵入，加注解即可，开发效率最高 |
| 秒杀抢购（预扣库存+创建订单） | 极高并发、极低延迟、热点资源竞争 | 最终一致 | Redis + Seata TCC | Redis 抗流量，TCC 手动控制资源预留，避免全局锁瓶颈 |
| 跨行转账（A行扣款+B行入账） | 短事务、低并发、资金安全第一 | 强一致 | Seata XA 模式 | 数据库原生两阶段提交，严格保证一致性 |
| 订单履约（创建→支付→发货→收货→结算） | 长流程、多步骤（10+服务）、耗时长 | 最终一致 | Seata SAGA 模式 | 长事务不适合锁资源，用补偿机制逐级回滚 |
| 保险理赔（报案→审核→定损→赔付） | 长流程、人工介入、耗时数天 | 最终一致 | Seata SAGA 模式 | 流程长且可能人工干预，需要补偿而非强锁 |
| 采购入库（采购单+入库单+应付账款） | 中等流程、跨部门系统 | 最终一致 | Seata AT 模式 或 SAGA | 步骤不多用 AT，步骤多用 SAGA |
| 机票+酒店预订（扣机票+扣酒店+支付） | 跨多个独立业务系统、中等并发 | 最终一致 | Seata AT 模式 | 跨服务但每个操作简单，AT 足够 |
| 多语言技术栈（Go+Java+PHP 混合） | 技术栈不统一 | 最终一致 | DTM | 唯一成熟的多语言分布式事务方案 |
| Java 核心交易（对性能有极致要求） | 高并发、愿接受 TCC 开发成本 | 最终一致 | ByteTCC | 嵌入式协调器，比 Seata TCC 性能高约 44% |
| 分库分表场景（核心需求是分库分表） | 数据量大、需要水平拆分 | 视业务而定 | ShardingSphere（LOCAL/XA/BASE） | 事务是中间件的附带能力，与分库分表一体化 |
| 异步通知类（支付成功后发短信/发货） | 不需要回滚、允许失败重试 | 最终一致 | RocketMQ 事务消息 | 比引入 Seata 更轻量，MQ 自带重试机制 |
| T+1 对账（日终对账、差错处理） | 实时性要求极低 | 最终一致 | 定时任务补偿 | 不需要分布式事务框架，离线补偿即可 |
三、Java常用框架
在 Java 生态中，分布式事务框架的选型需结合功能覆盖度、性能与语言适配综合判断：Seata 以多模式支持见长，是通用性最强的方案；DTM 定位轻量级协调器，核心优势在于多语言支持；ByteTCC 专注纯 TCC 实现，以性能为首要目标；ShardingSphere 则属于数据库中间件，分布式事务仅为其内嵌能力之一。此外，技术栈是选型的基础前提.NET 生态可考虑 OpenSagas-csharp 等平台专有实现，跨语言场景则 DTM 与 Oracle MicroTx 更为通用。
📊 同类框架对比
| 框架 | 支持语言 | 核心特点 | 适用场景 |
|---|---|---|---|
| Seata | Java | 提供 AT、TCC、SAGA、XA 四种模式，是 Java 生态中最成熟的分布式事务解决方案 | 绝大多数 Java 微服务场景，特别是追求低改造成本、需要 AT 模式快速接入的业务 |
| DTM | Go、Python、PHP、Java、C# 等 | 首款非 Java 语言的分布式事务管理器，通过子事务屏障技术，优雅解决了空补偿、悬挂、幂等等难题 | 语言栈非 Java，或公司内部包含 Go、PHP 等多种语言，需要统一分布式事务方案的多语言场景 |
| ByteTCC | Java | 嵌入式协调器的纯 TCC 实现，无需独立部署 TC 节点，事务上下文随业务请求透传，链路更短 | 对性能要求极高的 TCC 场景，尤其是 API 网关聚合、跨服务订单链路等高频接口场景 |
| ShardingSphere | Java 为主 | 分布式数据库中间件，分布式事务是其内嵌能力，支持 LOCAL、XA、BASE（集成 Seata AT）三种模式；强项在于分库分表 | 核心需求是分库分表、读写分离，事务只是附带能力；适合数据量大、需要水平拆分的业务场景 |
四、四种事务模式核心区别在于一致性强度、性能开销和代码侵入性。
📊 四种模式对比总结
| 对比维度 | AT | TCC | SAGA | XA |
|---|---|---|---|---|
| 一致性 | 最终一致 | 最终一致 | 最终一致 | 强一致 |
| 隔离性 | 全局锁保证 | 资源预留 | 无隔离 | 数据库锁保证 |
| 代码侵入性 | 极低 | 高 | 中 | 无 |
| 性能 | 中 | 高 | 高 | 低 |
| 适用事务长度 | 短 | 短 | 长 | 短 |
| 适用并发 | 中 | 高 | 高 | 低 |
| 依赖 | undo_log 表 | 业务方实现三方法 | 状态机定义 | 数据库 XA 支持 |
| 典型场景 | 常规下单 | 秒杀、支付 | 订单履约、理赔 | 银行转账 |