java微服务分布式事务需用最终一致性替代acid，常用方案包括本地消息表、rocketmq事务消息（需幂等消费）、seata的at/tcc/saga模式；应优先业务重构规避，辅以监控与人工补偿。

Java 中微服务架构下的分布式事务不能靠单体应用的本地事务（@Transactional）直接解决，因为每个服务有独立数据库，ACID 无法跨服务保证。核心思路是用“最终一致性”替代强一致性，结合补偿、消息、协调器等机制实现可靠的数据协同。

基于消息队列的最终一致性（最常用）

适用于大多数业务场景，如订单创建后扣减库存、支付成功后更新订单状态。关键在于确保“业务操作”和“发消息”原子执行，避免消息丢失或重复。

• 使用本地消息表：在业务库中建一张 message_log 表，与业务操作同事务写入（例如插入订单 + 插入待发送消息），再由独立线程/定时任务扫描并投递到 RocketMQ/Kafka；
• 利用事务消息（如 RocketMQ 的 Half Message）：先发预提交消息，业务执行成功后再发 Commit，失败则发 Rollback，MQ 会自动清理未确认消息；
• 消费端必须幂等：下游服务处理消息前查重（如用订单 ID + 状态做唯一约束），防止重复消费导致数据错乱。

Seata：开源分布式事务解决方案

Seata 提供 AT（自动补偿）、TCC、Saga 三种模式，其中 AT 模式对业务侵入最小，适合已有 JDBC 应用快速接入。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• AT 模式原理：Seata 在数据源层拦截 SQL，自动生成 undo_log 记录变更前镜像；提交时全局协调器（TC）统一通知各分支事务提交，异常时回滚各分支的 undo_log；
• 需引入 Seata 客户端（seata-spring-boot-starter），配置 application.yml 指向 Seata Server（TC），并在分布式调用入口加 @GlobalTransactional；
• 注意限制：不支持跨库 JOIN、DDL、存储过程；高并发下 undo_log 表可能成瓶颈，建议定期归档。

TCC 模式（适用于强一致要求高的场景）

将一个业务操作拆为 Try-Confirm-Cancel 三阶段，由开发者显式编码，灵活性高但开发成本大。

• Try 阶段：预留资源（如冻结账户余额、锁定库存），不做真实扣减；
• Confirm 阶段：真正执行（扣款、出库），仅当所有 Try 成功才触发，且必须可幂等；
• Cancel 阶段：释放预留资源，需能处理 Confirm 超时或失败后的补偿；
• 推荐搭配 Saga 模式管理长事务链路，用状态机或注解驱动流程（如 ServiceComb Pack 或 Seata TCC）。

避免过度设计：先评估是否真需要分布式事务

很多所谓“分布式事务需求”，其实可通过业务重构规避。

• 查询类操作尽量走异步同步（如 ES 或读库订阅 binlog），不参与事务；
• 把强依赖拆成“尽力而为+人工兜底”：比如优惠券发放失败，先记日志告警，再由运营后台补发；
• 聚合主数据下沉：用户中心统一管账户余额，订单服务只调用其接口，把分布式问题转为远程调用可靠性问题（配合重试+熔断）。

不复杂但容易忽略：无论选哪种方案，监控、日志追踪（如 SkyWalking 集成 Seata）、超时配置、人工干预入口（补偿任务平台）都得跟上，否则线上出问题只能靠翻日志硬查。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南