250 lines
7.7 KiB
Markdown
250 lines
7.7 KiB
Markdown
---
|
||
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-服务间通信]] — 消息投递的一致性保障
|