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