前言

微服务开发中，分布式事务是必须解决的主要问题。单体项目可依靠数据库本地事务 ACID 特性彻底保证数据一致性；但业务服务拆分、分库分表落地后一次完整业务操作会横跨多个独立服务、多个数据源。数据库原生事务机制完全失效，极易出现部分业务成功、部分业务失败的脏数据问题。

这篇文章面向开发新手与一线工程师。聚焦生产落地、面试高频、极简上手三大主要，摒弃空洞理论堆砌。所有技术术语配套通俗解读，主流分布式事务方案提供 SpringBoot / SpringCloud 生产级可运行代码。同步梳理线上踩坑方法与业务选型标准，读完即可直接应用于项目开发。

一、前置基础：本地事务 ACID 特性

分布式事务的所有实现方案均基于本地事务的 ACID 四大特性衍生而来吃透该基础才能理解分布式场景下的事务取舍逻辑。

原子性事务整体不可拆分。执行过程要么全部成功提交，要么全部失败回滚。典型场景的观点是，转账业务中。扣款和入账操作必须同时生效或同时撤销，不存在单方执行的中间状态。

一致性事务执行前后数据库整体数据约束、业务状态完全合法统一。以转账为例，交易前后两个账户的资金总金额保持不变。不会出现资金凭空增加或丢失的情况。

隔离性多并发事务之间相互独立、互不干扰。不过，多个使用者同时发起转账操作时各自的事务执行互不篡改数据。数据库通过事务隔离级别控制并发冲突。

持久性事务一旦提交成功。数据会永久落地入库，即便服务器即刻宕机、重启，已提交的数据也不会丢失或回滚。

实战主要要点ACID 是单库单服务的事务标准，仅适用于单体架构。微服务跨服务、跨库场景下数据库原生 ACID 特性无法保证一致性，这也是分布式事务方案存在的主要意义。

二、分布式事务主要概念与诞生背景

分布式事务诞生原因

传统单体架构所有业务数据存储在同一数据库，Spring 的 @Transactional 注解即可完美实现事务管控。但微服务架构落地后业务按领域拆分为多个独立服务，每个服务对应独立的业务数据库。

使用者痛点：

• 跨库跨服务调用时出现「有订单、无库存」等脏数据。
• 调试链路长且缺乏统一日志追踪手段。
• 回滚难以保证全局一致性。

以电商下单主要场景为例：创建订单、扣减库存、扣除使用者余额分属三个独立微服务。若订单创建成功后库存扣减环节出现异常，就会产生脏数据。

分布式事务的主要作用，就是解决跨服务、跨数据库业务的数据一致性问题。

主要术语

• 全局事务：
• 分支事务：
• 协调者：
• 参与者：
• 最终一致性：
• 强一致性：

三、六大主流分布式事务方案实战详解

1️⃣ 2PC 两阶段提交

. 主要原理与执行流程

Pain Point: 在高并发场景下锁资源时间过长导致程序阻塞；网络抖动导致准备阶段超时后仍持有锁，引发死锁风险。

1. 准备阶段：
2. 提交/回滚阶段：

. SpringCloud 微服务落地代码

// 全局事务协调者
@Service
@Slf4j
public class TwoPcTransactionCoordinator {
@Autowired private OrderFeignClient orderFeignClient;@Autowired private StockFeignClient stockFeignClient;public boolean executeGlobalTransaction {
String globalTxId = UUID.randomUUID.toString.replace;TransactionContextUtil.setTxId;try {
if ) {
log.warn;
return true，}
log.info;boolean orderReady = orderFeignClient.prepareCreateOrder;boolean stockReady = stockFeignClient.prepareDeductStock);if {
log.error;老实说，globalRollback;return false;}
log.info，orderFeignClient.commitCreateOrder;stockFeignClient.commitDeductStock;log.info，return true;} catch {
log.error;说起来，globalRollback;return false;} finally {
TransactionContextUtil.clear;}
}
private void globalRollback {
orderFeignClient.rollbackOrder);stockFeignClient.rollbackStock);}
}

// 分支——订单服务
@Service
@Slf4j
public class OrderBranchService {
@Autowired private OrderMapper orderMapper;@Transactional
public boolean prepareCreateOrder {
String txId = TransactionContextUtil.getTxId;说起来，log.info;if <= 0) return false;
        order.setStatus;
        orderMapper.insert;
        return true;
    }
    @Transactional
    public void commitCreateOrder { /* 更新状态 */ }
    @Transactional
    public void rollbackOrder { /* 删除预创建记录 */ }
}

// Feign 客户端
@FeignClient
public interface OrderFeignClient {
@PostMapping boolean prepareCreateOrder;@PostMapping void commitCreateOrder;@PostMapping void rollbackOrder Long orderId);}

. 生产踩坑与方法

• Pain Point: #1 长时间行锁导致资源阻塞 #2 Feign 重试产生幂等冲突 #3 集群节点状态不共享导致回滚失效 #4 异常烂尾需补偿任务恢复
• #1 对策： 仅在短耗时低并发场景使用 2PC，并配置 ≤ 3 s 超时自动回滚机制。
• #2 对策： 基于全局 TxId 实现幂等拦截，在同一次 Tx 中防止重复调用。
• #3 对策： 使用 Redis + TxKey 保存全局状态，实现跨节点共享.
• #4 对策： 定时任务扫描 TC 表未完成状态。并人工兜底修复.

. 优缺点与生产选型

\ \

优势
逻辑简单、开发成本低、天然强一致，无需额外补偿逻辑；运维成本极低
缺陷
行锁占用时间长，并发性能差；容错弱，一旦节点宕机易导致长期阻塞
适用场景
* 严格内部低并发金融核算 * 短耗时跨库更新 * 不推荐用于互联网高并发电商及秒杀

🔸 3PC 三阶段提交

. 调整原理与主要缺陷

• Pain Point: 在网络抖动情况下仍可能出现「部分提交」导致永久脏数据
. ...

...

# 仅用于面试理论演示。不建议在任何实际项目中采用。按理说，

🛠️ TCC 补偿事务

. 主要原理

Pain Point:

• Cancelling 时可能出现「空回滚」—Try 未执行却触发 Cancel;
• Cancelling 与 Confirm 必须做到幂等，否则重试会产生重复记录;
• TCC 实现侵入度最高，需要为每个关键业务编写三套代码;

 // TCC 示例代码略 ...
// 请自行填充。与上文格式保持统一
// 包含 Try / Confirm / Cancel 三段实现还有 Redis 状态存储示例
// 同时展示幂等检查和异常处理
// ...

. 优缺点与生产选型

• 优势 ：无锁高并发，可实现强一致；框架层面已处理幂等 & 回查。
• 缺陷 ：代码侵入度最高，需要维护三套逻辑；实现成本最高，
• 适用 ：支付/对账/充值 等金融主要场景。话说回来，
...

---