微服务架构下的分布式事务实战：从理论到生产落地

在微服务架构中，数据一致性是最具挑战性的问题之一。单个数据库的 ACID 事务被拆分到多个独立服务后，如何保证跨服务的数据一致性，是每个架构师必须面对的课题。本文将从理论基础出发，系统解构分布式事务的核心解决方案，并分享在生产环境中的落地实践。

一、为什么微服务需要分布式事务

1.1 单体架构到微服务的演进

传统单体应用依赖单个数据库的本地事务（BEGIN/COMMIT/ROLLBACK），所有操作共享同一个数据库连接，ACID 特性天然成立。但在微服务架构下：

1.2 典型业务场景

电商下单流程是最经典的分布式事务场景：

[用户下单] → 订单服务(创建订单, status=PENDING)
           → 库存服务(扣减库存)
           → 账户服务(扣减余额)
           → 积分服务(增加积分)
           → 订单服务(更新订单, status=PAID)

这个流程涉及 4 个独立服务，任何一步失败都需要回滚前面已成功的操作，典型的"Saga"模式场景。

二、分布式事务的理论基石

2.1 CAP 定理的权衡

Eric Brewer 在 2000 年提出的 CAP 定理指出，在一个分布式系统中，一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)三者不可兼得，最多只能同时满足两个：

• CA 系统：放弃分区容错，传统关系型数据库（如单机 MySQL）
• CP 系统：放弃强一致时的可用性，如 ZooKeeper、etcd、分布式锁服务
• AP 系统：放弃强一致性，保证高可用，如 DynamoDB、Cassandra

💡 注意：CAP 中的 P（分区容错）是分布式系统的必然前提，实际选择是在 C 和 A 之间权衡。

2.2 BASE 理论的补充

BASE 是对 CAP 中 AP 方案的理论扩展，核心思想是最终一致性：

• Basically Available（基本可用）：允许损失部分可用性，如降级、限流
• Soft State（软状态）：允许数据存在中间状态
• Eventual Consistency（最终一致性）：经过一段时间后，数据达到一致状态

2.3 FLP 不可能定理

Fischer、Lynch、Paterson 在 1985 年证明：在异步分布式系统中，即使只有一个进程可能崩溃，也不存在确定性算法能解决共识问题。这意味着我们需要在"确定性"和"活性(Liveness)"之间做出取舍——这也是为什么 Paxos/Raft 需要 Leader 和超时机制的原因。

三、核心解决方案全景对比

3.1 两阶段提交(2PC, Two-Phase Commit)

2PC 是最经典的分布式事务协议，将事务过程分为两个阶段：

阶段一：投票阶段(Prepare Phase)

1. 协调者(Coordinator)向所有参与者(Participant)发送 PREPARE 请求
2. 参与者执行事务操作（写 undo/redo log），但不提交
3. 参与者向协调者返回 YES（成功）或 NO（失败）

阶段二：提交阶段(Commit Phase)

1. 如果所有参与者返回 YES，协调者发送 COMMIT 请求
li如果有任一参与者返回 NO，协调者发送 ROLLBACK 请求
2. 参与者执行提交或释放锁

        Coordinator          Participant A        Participant B
            |                     |                     |
            |--- PREPARE -------->|                     |
            |--- PREPARE ----------------------------->|
            |                     |                     |
            |<-- YES -------------|                     |
            |<-- YES ----------------------------------|
            |                     |                     |
            |--- COMMIT --------->|                     |
            |--- COMMIT -------------------------->   |
            |                     |                     |
                                     

2PC 的致命问题：

• 同步阻塞：参与者在 PREPARE 后持有锁等待，资源占用时间长
• 协调者单点：协调者故障会导致参与者无限等待（即使 Raft/Paxos 解决了协调者高可用，协议本身仍是阻塞的）
• 数据不一致：部分参与者 COMMIT 成功，部分失败（脑裂场景）

⚠️ 生产建议：2PC 协议本身不适合高并发微服务场景，但其思想被 XA 规范和 Seata AT 模式等改进方案继承。

3.2 三阶段提交(3PC, Three-Phase Commit)

3PC 在 2PC 之间插入了一个 PreCommit 阶段，试图解决同步阻塞问题：

阶段一：CanCommit—协调者询问参与者是否有能力执行事务（不执行操作）。

阶段二：PreCommit—所有参与者同意，协调者发送 PreCommit，参与者执行事务但不提交。

阶段三：DoCommit—所有参与者 PreCommit 成功，协调者发送 Commit；否则发送 Abort。

改进点：引入了超时机制——参与者在 PreCommit 阶段超时未收到 DoCommit 会默认执行 Commit（降低阻塞）。

局限：网络分区场景下仍可能出现不一致。3PC 更多是理论完善，实际工程中使用较少。

3.3 补偿事务(TCC, Try-Confirm-Cancel)

TCC 是一种业务层面的分布式事务方案，不依赖数据库事务，而是通过业务逻辑实现一致性：

典型实现：电商下单场景

// 订单服务 - Try
public boolean tryCreateOrder(OrderRequest request) {
    // 创建订单，状态 = PENDING（资源预留）
    Order order = new Order();
    order.setStatus(OrderStatus.PENDING);
    orderMapper.insert(order);
    return true;
}

// 库存服务 - Try  
public boolean tryDeductStock(Long productId, int count) {
    // 检查库存充足
    if (stockMapper.getAvailable(productId) < count) {
        throw new BusinessException("库存不足");
    }
    // 预扣：减少可用库存，增加冻结库存
    stockMapper.freeze(productId, count);
    return true;
}

// 库存服务 - Confirm
public boolean confirmDeductStock(Long productId, int count) {
    // 正式扣减：减少冻结库存
    stockMapper.confirmDeduct(productId, count);
    return true;
}

// 库存服务 - Cancel
public boolean cancelDeductStock(Long productId, int count) {
    // 回滚：释放冻结库存，恢复可用库存
    stockMapper.unfreeze(productId, count);
    return true;
}

TCC 的挑战：

• 空回滚：Try 未执行就收到 Cancel——需要记录 Try 执行状态
• 悬挂：Cancel 先于 Try 执行——Cancel 执行后拒绝 Try
• 幂等：Confirm/Cancel 需要支持幂等调用（网络重试）

💡 实践要点：使用事务控制表记录 Try 状态（transaction_id + status），解决空回滚和悬挂问题。

3.4 Saga 模式

Saga 是一种长事务拆分方案，将分布式事务拆分为一系列本地事务，每个本地事务完成后发布事件触发下一个事务。如果某一步失败，则按反序执行补偿事务。

两种实现方式：

编排式(Choreography)：无中心协调者，服务间通过事件驱动

[订单服务] --OrderCreated--> [库存服务] 
                        --StockReserved--> [支付服务]
                        --PaymentProcessed--> [积分服务]
                        --PointsAdded--> [订单服务(Completed)]
                        
// 失败时反向补偿
[支付服务失败] --PaymentFailed--> [库存服务(Released)]
                          --StockReleased--> [订单服务(Cancelled)]

编排式(Orchestration)：中央 Saga 编排器协调流程

-- 1. 在同一本地事务中执行业务操作 + 写入消息表
BEGIN TRANSACTION;
    -- 业务操作
    UPDATE user SET balance = balance - 100 WHERE user_id = 1;
    
    -- 写入本地消息表
    INSERT INTO message_table (topic, payload, status)
    VALUES ('payment_success', '{"orderId":123,"amount":100}', 'PENDING');
COMMIT;

-- 2. 独立作业扫描待发送消息
SELECT * FROM message_table 
WHERE status = 'PENDING' AND retry_count < 5 
ORDER BY created_at LIMIT 100;

-- 3. 发送消息给下游服务（MQ 或 RPC）
-- 4. 成功后更新状态为 SENT
UPDATE message_table SET status = 'SENT' WHERE id = ?;

-- 5. 兜底：定时扫描超时未发送的消息重试

[业务服务] → 本地事务写入 Outbox 表
          → CDC 工具(Debezium/Canal) 读取 Binlog
          → 发布到消息队列(Kafka/RocketMQ)
          → 下游消费者接收消息

1. 是否必须强一致性(CP)?
   ├─ 是 → 评估 XA / Seata XA（注意性能损耗）
   └─ 否 ↓
   
2. 是否跨系统(不同技术栈)?
   ├─ 是 → 消息最终一致(RocketMQ事务消息) / Saga编排
   └─ 否 ↓

3. 事务链路长短?
   ├─ 短(≤3步) → TCC / Seata AT
   └─ 长(>3步) → Saga编排

4. 性能要求?
   ├─ 高TPS → TCC / 本地消息表
   └─ 一般 → Seata AT / Saga

5. 是否已有Kafka/RocketMQ?
   ├─ 是 → 优先考虑事务消息
   └─ 否 → TCC或本地消息表（减少依赖）

[TM: Transaction Manager]  发起/结束全局事务
[RM: Resource Manager]     分支事务的执行者（各微服务）
[TC: Transaction Coordinator] 事务协调者（独立部署）

执行流程：
1. TM 向 TC 开启全局事务（生成 XID）
2. RM 执行本地业务 SQL，提交前解析 SQL 生成 UNDO_LOG
3. RM 向 TC 注册分支事务
4. TC 通知全局提交/回滚
5. 提交：异步删除 UNDO_LOG
6. 回滚：根据 UNDO_LOG 生成反向补偿 SQL

// 1. 引入依赖
// implementation 'io.seata:seata-spring-boot-starter:1.7.0'

// 2. 配置 seata.conf
seata:
  tx-service-group: my_tx_group
  service:
    vgroup-mapping:
      my_tx_group: default
  enabled: true
  application-id: order-service

// 3. 使用全局事务
@GlobalTransactional(name = "create-order", rollbackFor = Exception.class)
public void createOrder(OrderRequest request) {
    // 本地事务
    orderMapper.insert(order);
    
    // 远程调用（通过Feign + Seata代理）
    stockService.deduct(request.getProductId(), request.getCount());
    accountService.debit(request.getUserId(), request.getAmount());
}

CREATE TABLE `undo_log` (
  `branch_id` BIGINT NOT NULL COMMENT 'branch transaction id',
  `xid` VARCHAR(128) NOT NULL COMMENT 'global transaction id',
  `context` VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
  `rollback_info` LONGBLOB NOT NULL COMMENT 'rollback info',
  `log_status` INT NOT NULL COMMENT '0:normal status,1:defense status',
  `log_created` DATETIME(6) NOT NULL COMMENT 'create datetime',
  `log_modified` DATETIME(6) NOT NULL COMMENT 'modify datetime',
  UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

alerting:
  rules:
    - name: transaction-success-rate
      expr: rate(seata_transaction_success[5m]) < 0.999
      for: 5m
      severity: warning
      summary: "全局事务成功率低于99.9%"
    
    - name: transaction-rollback-spike
      expr: delta(seata_transaction_rollback[5m]) > 50
      for: 1m
      severity: critical
      summary: "事务回滚量突增"
    
    - name: outbox-backlog
      expr: outbox_pending_messages > 10000
      for: 10m
      severity: warning
      summary: "发件箱消息积压过高"

-- 乐观锁实现
UPDATE stock 
SET available = available - #{count}, version = version + 1
WHERE product_id = #{productId} 
  AND available >= #{count}
  AND version = #{version};
  
-- 检查影响行数，为0则重试