---
tags: [microservice, distributed-transactions, saga, tcc, outbox]
create time: 2026-05-05
---

# 分布式事务

## 概述

每个服务拥有独立数据库，跨服务的"一次操作"实际上涉及**多个本地事务**。如何保证这些本地事务要么全部成功、要么全部回滚，就是分布式事务要解决的问题。

```mermaid
graph LR
    A["用户下单"] --> B["订单服务<br/>写库"]
    B --> C["库存服务<br/>扣减"]
    C --> D["支付服务<br/>扣款"]
    
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#fff3e0
    style D fill:#fff3e0
```

## 分布式事务方案全景

| 方案 | 一致性级别 | 性能 | 复杂度 | 适用场景 |
|------|-----------|------|--------|---------|
| **本地事务 + MQ 事件** | 最终一致 | ⭐⭐⭐⭐⭐ | ⭐ | 绝大多数场景 |
| **Saga 模式** | 最终一致 | ⭐⭐⭐ | ⭐⭐ | 长流程业务 |
| **TCC** | 强最终一致 | ⭐⭐⭐ | ⭐⭐⭐⭐ | 对一致性要求较高的场景 |
| **AT 模式 (Seata)** | 伪强一致 | ⭐⭐ | ⭐ | 不想改业务代码时 |

> [!tip] 选择策略
> **先默认用本地事务 + 异步事件（最简单、最高效）**，只有在业务明确需要 Saga 或 TCC 时才升级。80% 的场景，本地事务 + MQ 就足够了。

## 方案一：本地事务 + 消息队列

核心思想：**将"数据变更 + 发消息"合并到一个本地事务中。**

### Outbox 模式（推荐）

```mermaid
sequenceDiagram
    participant App as 应用服务
    participant DB as 数据库
    participant Outbox as Outbox 表
    participant MQ as 消息队列
    participant Sub as 订阅方

    App->>DB: BEGIN 事务
    App->>DB: 写业务数据
    App->>Outbox: 写入待发送消息
    App->>DB: COMMIT
    
    loop 定时任务
        MQ->>Outbox: 扫描 status='pending'
        Outbox-->>MQ: 返回消息列表
        MQ->>Sub: 投递消息
        MQ->>Outbox: 更新为 'sent'
    end
    
    Note right of Sub: 至少一次投递 + 消费者幂等
```

#### Outbox 表建表示例

```sql
CREATE TABLE outbox (
    id          BIGSERIAL PRIMARY KEY,
    topic       VARCHAR(255) NOT NULL,     -- 消息主题
    payload     JSONB      NOT NULL,       -- 消息体
    status      VARCHAR(20)  NOT NULL DEFAULT 'pending', -- pending / sent / failed
    error_msg   TEXT,                       -- 失败原因
    created_at  TIMESTAMP    NOT NULL DEFAULT NOW(),
    sent_at     TIMESTAMP
);

-- 加速定时扫描查询
CREATE INDEX idx_outbox_pending ON outbox (status, created_at) 
WHERE status = 'pending';
```

```go
// Go 示例：出事务内同时写业务数据和 outbox 记录
tx, _ := db.Begin()
tx.Exec("INSERT INTO orders (user_id, total) VALUES ($1, $2)", userID, total)
tx.Exec(`INSERT INTO outbox (topic, payload, status) 
         VALUES ('order.created', $1, 'pending')`, jsonPayload)
tx.Commit()

// 后台 goroutine 轮询并推送
func outboxWorker(ctx context.Context, ticker *time.Ticker) {
    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            sendPendingMessages(ctx)
        }
    }
}
```

#### 事务消息（RocketMQ 原生支持）

如果使用的是 RocketMQ，可以绕过 Outbox 模式直接用事务消息：

```go
// 发送事务消息
txMsg := rocketmq.NewTransactionMessage("order-created", payload)
localTx := &MyLocalTxChecker{}

// half 消息发送 → 本地事务执行 → 提交/回查
res, _ := producer.SendMessageInTransaction(txMsg, localTx)
```

RocketMQ 的事务消息流程：
1. 生产者发送 "half 消息" 到 MQ（消费者不可见）
2. 执行本地事务
3. 根据结果 Commit（消费者可见）或 Rollback（丢弃）
4. 如果步骤 2 超时，MQ 回查本地事务状态

### 消费幂等性

> [!warning] 关键保障
> 消息可能重复投递（网络超时、MQ 重投），消费者必须做到**幂等**——处理一次和处理多次的结果完全相同。

**三种常见策略：**

| 策略 | 实现方式 | 适用场景 |
|------|---------|---------|
| **数据库唯一约束** | `msg_id` 做 `UNIQUE` | 最可靠，推荐首选 |
| **Redis 去重键** | `SET dedup:{msg_id} 1 NX EX 86400` | 高吞吐场景 |
| **乐观锁版本控制** | `UPDATE SET qty = qty - N WHERE version = V` | 金额调整类操作 |

```go
// 推荐方案：利用 UNIQUE 约束做幂等保障
_, err := db.Exec(`
    INSERT INTO order_events (msg_id, order_id, action, amount)
    VALUES ($1, $2, $3, $4)
    ON CONFLICT (msg_id) DO NOTHING
`, msgID, orderID, action, amount)

if !isUniqueViolation(err) {
    log.Error("process message failed", err)
    return
}
// 执行业务逻辑——到这里说明消息是新到达的
```

## 方案二：Saga 模式

Saga 适用于**跨多个服务的长流程操作**，将大事务拆成一系列本地小事务，每个步骤都有对应的补偿操作。

### 编排式 vs 编舞式

```mermaid
graph TB
    subgraph ORCHESTRATION["编排式 — Coordinator 中心化"]
        CO[Coordinator] --> S1[OrderSvc: Create]
        CO --> S2[InventorySvc: Reserve]
        CO --> S3[PaymentSvc: Charge]
        
        S1 -.->|失败→Cancel| CO
        S2 -.->|失败→Cancel| CO
        S3 -.->|失败→Cancel| CO
    end

    subgraph CHOREOGRAPHY["编舞式 — 事件驱动"]
        E1[OrderCreated] --> S11[OrderService]
        S11 --> E2[StockReserved]
        E2 --> S12[InventoryService]
        S12 --> E3[PaymentCharged]
        E3 --> S13[PaymentService]
        
        S13 -.-> E4[PaidFailed] -.-> S11
    end
```

| 维度 | 编排式 | 编舞式 |
|------|--------|--------|
| **控制流** | 中心化 Coordinator | 各服务通过事件自发响应 |
| **可观测性** | ✅ 集中管理全流程 | ❌ 流程散布在各服务 |
| **耦合度** | 依赖 Coordinator | 服务间仅感知事件 |
| **适合规模** | 5~15 步的 Saga | 简单链路 (< 5 步) |

### Saga 补偿设计原则

每个正向操作必须有对应的**反向补偿**：

| 正向操作 | 补偿操作 |
|---------|---------|
| 创建订单 | 取消订单 |
| 预留库存 | 释放库存 |
| 扣款 | 退款 |
| 发送通知 | 撤销通知（一般不需要） |

> [!warning] 补偿操作的幂等性
> 补偿操作也必须幂等——CancelOrder 可能被触发多次。用订单状态的流转来保证（如只有 PENDING 才能转到 CANCELLED）。

## 方案三：TCC (Try-Confirm-Cancel)

TCC 在每个事务步骤中实现三个接口：

```
Try:   预留资源（冻结余额 / 锁定库存）
Confirm: 确认使用资源（正式扣减 / 正式锁定）
Cancel:  释放资源（解冻余额 / 解锁库存）
```

### TCC 时序图

```mermaid
sequenceDiagram
    participant Orch as Coordinator
    participant O as Order Service
    participant I as Inventory Service
    participant P as Payment Service
    
    Orch->>O: Try(CreateOrder)
    O-->>Orch: OK
    
    Orch->>I: Try(ReserveStock)
    I-->>Orch: OK
    
    Orch->>P: Try(ChargeBalance)
    P-->>Orch: OK
    
    Orch->>O: Confirm
    Orch->>I: Confirm
    Orch->>P: Confirm
    
    Note over Orch,P: 全部 Confirm → 事务完成
```

### TCC vs Saga 对比

| 维度 | TCC | Saga |
|------|-----|------|
| 一致性强度 | 较强（资源被占用期间不允许其他事务使用） | 较弱（中间态数据可见） |
| 开发成本 | 高（每个业务方法实现 Try/Confirm/Cancel） | 低（只需正向 + 反向操作） |
| 性能 | 中（需要两阶段提交） | 中高（单阶段本地事务） |
| 适用场景 | 资金、库存等高敏感业务 | 订单流程、审批流等业务链 |

## 关联笔记

- [[03-数据一致性/01-数据库拆分]] — 数据库拆分是分布式事务的前提
- [[02-服务治理/06-容错模式]] — 熔断器和重试在分布式事务中的作用
- [[02-服务治理/05-服务间通信]] — 消息投递的一致性保障