一、前言
在单体应用中，事务一般由关系型数据库本身来保证，通过 ACID 特性实现数据一致性。但随着微服务架构的普及，应用被拆分为多个独立服务，数据可能分散在不同数据库、不同存储引擎中，传统的单机事务无法再覆盖。
这就引出了 分布式事务 的问题：如何在多服务、多数据库场景下，仍然保证数据一致性？
本文将结合 Spring Boot 实际开发，对常见的几种分布式事务方案进行解析：
XA 方案（两阶段提交，强一致性）
Seata（柔性事务，常用于阿里系微服务）
本地消息表 + 最终一致性（高可用场景的常见落地方案）
同时会总结它们的 优缺点、常见坑点与适用场景。
二、分布式事务常见场景
在 Spring Boot 开发中，以下场景经常涉及分布式事务：
订单系统：创建订单 → 扣减库存 → 扣减余额
支付系统：支付成功 → 修改订单状态 → 发送消息通知 → 更新积分
营销系统：用户下单 → 触发优惠券核销 → 更新活动数据
这些流程往往跨越多个服务和数据库，如果其中一步失败，就可能导致数据不一致，例如：
库存已扣减，但订单未生成
订单已支付，但未发货
优惠券已核销，但活动未更新
因此需要合理的分布式事务方案来保证一致性。
三、XA 方案（两阶段提交）
1. 原理
XA 是 分布式事务标准协议，基于两阶段提交（2PC，Two Phase Commit）：
阶段一：事务协调者向所有数据库发送
prepare，各数据库执行但不提交，返回可提交状态阶段二：如果所有数据库都返回成功，则发送
commit，否则发送rollback
2. 在 Spring Boot 中的实现
常见实现方式是 Atomikos、Narayana 等第三方事务管理器，也可以结合 JTA 来管理。
示例配置（Atomikos）：
spring:
jta:
enabled: true
atomikos:
properties:
service: com.atomikos.icatch.standalone.UserTransactionServiceFactory
3. 优缺点
✅ 优点
强一致性保证
对开发透明，业务代码几乎不用改
❌ 缺点
性能差：两阶段提交会增加锁时间，导致吞吐量下降
扩展性差：跨多数据源时容易成为瓶颈
单点风险：协调者挂掉可能导致事务悬挂
4. 适用场景
适合金融级场景（如银行转账）——必须保证强一致性，但对性能要求相对次要。
四、Seata（柔性事务）
1. 原理
Seata 是阿里开源的分布式事务解决方案，支持 AT 模式、TCC 模式、Saga 模式：
AT 模式：自动代理数据源，类似本地事务 + Undo Log 回滚，开发成本低
TCC 模式：需要业务实现 Try/Confirm/Cancel 三个接口，粒度更细，性能更高
Saga 模式：长事务补偿，适合跨服务调用链较长的业务
2. 在 Spring Boot 中集成
依赖：
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<version>1.7.1</version>
</dependency>
配置：
seata:
enabled: true
application-id: order-service
tx-service-group: my_tx_group
service:
vgroup-mapping:
my_tx_group: default
使用：
@GlobalTransactional
public void createOrder(Order order) {
orderDao.save(order);
inventoryService.deduct(order.getId());
}
3. 优缺点
✅ 优点
透明代理数据库，AT 模式对开发友好
多种事务模式可选，适配不同业务场景
社区活跃，生态完善
❌ 缺点
需要额外部署 Seata Server
Undo Log 占用空间，长事务性能下降
某些复杂 SQL（批量更新/存储过程）支持有限
4. 适用场景
电商下单、库存扣减等典型 高并发场景，对性能要求较高，能接受短时间的不一致。
五、本地消息表（最终一致性）
1. 原理
核心思想是 业务数据 + 消息发送放在同一个本地事务中，通过消息队列来保证最终一致性：
业务服务在本地事务中写入业务表 + 消息表
定时任务扫描消息表，发送消息到 MQ
消费者消费 MQ 消息，执行后续逻辑
成功后更新消息表状态
2. 在 Spring Boot 中实现
数据库表：
CREATE TABLE t_outbox_message (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
content TEXT NOT NULL,
status TINYINT DEFAULT 0,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
业务代码：
@Transactional
public void createOrder(Order order) {
orderDao.insert(order);
outboxDao.insert(new OutboxMessage(order));
}
定时任务发送消息：
@Scheduled(fixedRate = 5000)
public void sendPendingMessages() {
List<OutboxMessage> messages = outboxDao.findPending();
for (OutboxMessage msg : messages) {
mqProducer.send(msg);
outboxDao.markSent(msg.getId());
}
}
3. 优缺点
✅ 优点
无需额外中间件，简单可靠
高可用，适合最终一致性场景
❌ 缺点
开发成本较高，需要写消息表逻辑
延迟一致性（可能有几秒的延迟）
消息补偿、幂等处理逻辑复杂
4. 适用场景
订单系统、积分系统、日志收集等对 最终一致性容忍度高 的业务。
六、三种方案对比
| 方案 | 一致性 | 性能 | 开发成本 | 典型场景 |
|---|---|---|---|---|
| XA | 强一致 | 低 | 低 | 银行转账、核心金融业务 |
| Seata | 最终一致（AT/TCC） | 中高 | 中 | 电商下单、库存、支付 |
| 本地消息表 | 最终一致 | 高 | 高 | 营销、积分、日志系统 |
七、常见坑点总结
XA 事务悬挂：协调者挂掉可能导致数据库锁未释放
Seata Undo Log 膨胀：要定期清理，否则影响性能
本地消息表补偿失败：要考虑消息幂等、死信队列机制
八、结语
分布式事务没有“银弹”，不同方案适合的场景完全不同：
金融强一致 → 优先考虑 XA
电商高并发 → 选择 Seata AT/TCC
最终一致性即可 → 本地消息表是首选
在 Spring Boot 实践中，建议结合 业务场景 + 性能要求 + 容错能力 来选择合适的方案，而不是盲目套用。