549 lines
19 KiB
Markdown
549 lines
19 KiB
Markdown
---
|
||
tags: [microservice, distributed-transactions, saga, tcc, outbox, seata, idempotency, dlq]
|
||
create time: 2026-05-17 15:00
|
||
---
|
||
|
||
# 分布式事务
|
||
|
||
## 概述
|
||
|
||
每个服务拥有独立数据库，跨服务的"一次操作"实际上涉及**多个本地事务**。如何保证这些本地事务要么全部成功、要么全部回滚，就是分布式事务要解决的问题。
|
||
|
||
```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)
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
### 消费幂等性
|
||
|
||
> [!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
|
||
}
|
||
// 执行业务逻辑——到这里说明消息是新到达的
|
||
```
|
||
|
||
#### 事务消息 vs Outbox
|
||
|
||
> [!question] 思考一下
|
||
> Outbox 模式有一个天然缺点：定时轮询有延迟（通常秒级）。如果你需要**毫秒级的延迟敏感型通知**（如支付结果实时推送到用户端），该怎么办？
|
||
|
||
如果使用的是 RocketMQ，可以绕过 Outbox 模式直接用事务消息：
|
||
|
||
```go
|
||
// 发送事务消息
|
||
txMsg := rocketmq.NewTransactionMessage("order-created", payload)
|
||
localTx := &MyLocalTxChecker{}
|
||
|
||
// half 消息发送 → 本地事务执行 → 提交/回查
|
||
res, _ := producer.SendMessageInTransaction(txMsg, localTx)
|
||
```
|
||
|
||
RocketMQ 事务消息的完整交互流程：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant Producer as 生产者
|
||
participant Broker as MQ Broker
|
||
participant DB as 业务数据库
|
||
participant Consumer as 消费者
|
||
|
||
Producer->>Broker: ① 发送 Half Message (消费者不可见)
|
||
Broker-->>Producer: ACK
|
||
|
||
Producer->>DB: ② 执行本地事务
|
||
alt 本地事务成功
|
||
Producer->>Broker: ③a Commit (消息对消费者可见)
|
||
else 本地事务失败
|
||
Producer->>Broker: ③b Rollback (消息丢弃)
|
||
end
|
||
|
||
Note over Producer,Broker: ④ 如果步骤 2 超时未回复
|
||
Broker->>Producer: ④ 回查请求 (CheckLocalTx)
|
||
Producer->>DB: 查询本地事务状态
|
||
DB-->>Producer: 返回 COMMIT / ROLLBACK
|
||
Producer->>Broker: 回查结果
|
||
```
|
||
|
||
> [!important] 回查机制的意义
|
||
> 当生产者执行本地事务过程中发生崩溃或网络中断，Broker 收不到 Commit/Rollback 指令，就会通过回查主动询问生产者。这确保了 **half 消息最终一定会收敛到可见或被丢弃**，不会出现悬空状态。
|
||
|
||
**可靠性要点清单：**
|
||
- ✅ 业务数据库和 Outbox 必须在**同一个本地事务**中写入
|
||
- ✅ 消费者必须有幂等保护（否则至少一次投递 = 无限次重复）
|
||
- ✅ 定时扫描任务需要设置最大重试次数，超过后进入人工处理
|
||
- ✅ 生产环境建议配置 **DLQ（死信队列）**，将连续消费失败的消息归档
|
||
|
||
## 方案二：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）。
|
||
|
||
### 编排式实现示例 (Go)
|
||
|
||
编排式的核心是一个 **Saga Coordinator**，它维护着当前步骤的执行状态和已完成的正向/反向操作列表：
|
||
|
||
```go
|
||
// Step 定义一个 Saga 步骤
|
||
type Step struct {
|
||
Name string
|
||
Execute func(ctx context.Context) error // 正向操作
|
||
Compensation func(ctx context.Context) error // 补偿操作
|
||
}
|
||
|
||
// Orchestrator 编排器
|
||
type Orchestrator struct {
|
||
steps []Step
|
||
executed []string // 已完成步骤名，用于补偿时逆向遍历
|
||
}
|
||
|
||
func (o *Orchestrator) AddStep(name string, exec, compens func(context.Context) error) {
|
||
o.steps = append(o.steps, Step{Name: name, Execute: exec, Compensation: compens})
|
||
}
|
||
|
||
// Execute 按顺序执行所有步骤，任一步骤失败则逆向补偿
|
||
func (o *Orchestrator) Execute(ctx context.Context) error {
|
||
for i, step := range o.steps {
|
||
if err := step.Execute(ctx); err != nil {
|
||
log.Error("step failed", z.String("step", step.Name), z.Err(err))
|
||
// 逆向补偿：从后往前执行已完步骤的补偿操作
|
||
o.rollback(ctx, i-1)
|
||
return fmt.Errorf("saga failed at %s: %w", step.Name, err)
|
||
}
|
||
o.executed = append(o.executed, step.Name)
|
||
}
|
||
return nil
|
||
}
|
||
|
||
func (o *Orchestrator) rollback(ctx context.Context, upTo int) {
|
||
for i := len(o.executed) - 1; i >= 0 && i <= upTo; i-- {
|
||
// 找到对应步骤的补偿函数并执行
|
||
step := o.steps[i]
|
||
if err := step.Compensation(ctx); err != nil {
|
||
log.Warn("compensation also failed — need manual intervention", z.String("step", step.Name))
|
||
// 补偿失败必须告警！人工介入处理
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
使用方式——构建一个下单 Saga：
|
||
|
||
```go
|
||
saga := &Orchestrator{}
|
||
|
||
saga.AddStep("create_order",
|
||
func(ctx context.Context) error { return orderSvc.Create(ctx, req) }, // 正向
|
||
func(ctx context.Context) error { return orderSvc.Cancel(ctx, orderID) }, // 反向
|
||
)
|
||
saga.AddStep("reserve_stock",
|
||
func(ctx context.Context) error { return stockSvc.Reserve(ctx, productIDs) },
|
||
func(ctx context.Context) error { return stockSvc.Release(ctx, productIDs) },
|
||
)
|
||
saga.AddStep("charge_payment",
|
||
func(ctx context.Context) error { return paySvc.Charge(ctx, amount) },
|
||
func(ctx context.Context) error { return paySvc.Refund(ctx, orderID) },
|
||
)
|
||
|
||
err := saga.Execute(ctx)
|
||
```
|
||
|
||
> [!note] 关键理解：补偿的局限性
|
||
>
|
||
> - **补偿不是撤销**：取消订单不会把商品退回到原始状态，而是创建一条反向业务记录
|
||
> - **补偿可能失败**：如果退款接口也挂了，你需要重试 + 告警 + 人工介入机制
|
||
> - **时间窗口问题**：如果正向前向到了第 5 步、补偿到了第 2 步时第 2 步也失败了，第 3~4 步的正向操作已经发生且无法撤销
|
||
|
||
## 方案三：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） | 低（只需正向 + 反向操作） |
|
||
| 性能 | 中（需要两阶段提交） | 中高（单阶段本地事务） |
|
||
| 适用场景 | 资金、库存等高敏感业务 | 订单流程、审批流等业务链 |
|
||
|
||
## 方案四：AT 模式 (Seata)
|
||
|
||
> [!question] 什么时候该用 Seata？
|
||
>
|
||
> 如果你的团队**不愿或没有能力为每个业务方法编写 TCC 接口**，但又有跨库事务需求——Seata 的 AT 模式就是为此设计的。它是"零侵入"的最强候选方案。
|
||
|
||
Seata AT 模式的核心原理是 **全局锁 + 二阶段提交**，业务代码不需要任何改动：
|
||
|
||
```
|
||
第一阶段（Global Lock）:
|
||
1. 拦截 SQL → 解析前后镜像
|
||
2. 申请全局锁（锁住被修改的行）
|
||
3. 本地事务执行（含 undo_log 写入）
|
||
4. 提交本地事务（全局锁暂不释放）
|
||
|
||
第二阶段（Global Commit/Rollback）:
|
||
Commit: 异步删除 undo_log，释放全局锁
|
||
Rollback: 利用 undo_log 生成反向 SQL，回滚并释放全局锁
|
||
```
|
||
|
||
### AT 模式时序图
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant TC as Transaction Coordinator<br/>(Seata Server)
|
||
participant TM as Transaction Manager<br/>(应用 A)
|
||
participant RS1 as Resource 1<br/>(订单 DB)
|
||
participant RS2 as Resource 2<br/>(库存 DB)
|
||
|
||
TM->>TC: 开启全局事务 (xid)
|
||
TM->>RS1: BEGIN; UPDATE orders SET ...
|
||
Note over RS1: 自动捕获 BEFORE/AFTER 镜像<br/>写入 undo_log
|
||
|
||
TM->>RS2: BEGIN; UPDATE stock SET qty = qty - 1
|
||
Note over RS2: 同样写 undo_log
|
||
|
||
TM->>RS1: COMMIT (本地事务完成)
|
||
TM->>RS2: COMMIT (本地事务完成)
|
||
|
||
TM->>TC: 报告二阶段提交完成
|
||
TC-->>RS1: 异步清理 undo_log
|
||
TC-->>RS2: 异步清理 undo_log
|
||
```
|
||
|
||
### AT 与 XA 的区别
|
||
|
||
很多人混淆 AT 和 XA——它们都是两阶段提交，但实现方式完全不同：
|
||
|
||
| 维度 | XA 模式 | AT 模式 (Seata) |
|
||
|------|---------|----------------|
|
||
| **锁粒度** | 数据库级（长事务锁） | 行级（短期全局锁） |
|
||
| **隔离级别** | 需要 SERIALIZABLE | 基于脏读 + 全局锁 |
|
||
| **性能** | 较差（锁持有时间长） | 较好（本地事务快速提交后异步清理） |
|
||
| **侵入性** | 需配置 DataSource Proxy | 零侵入，自动代理 JDBC |
|
||
|
||
### 使用注意事项
|
||
|
||
```go
|
||
// Seata Go SDK — 几乎零侵入
|
||
import "github.com/seata/seata-sdk-go-client/tx"
|
||
|
||
func CreateOrder(ctx context.Context, req *Request) error {
|
||
// 只需添加这一个注解
|
||
tx.GlobalTransaction()
|
||
|
||
// 下面的代码完全不变——Seata 自动代理数据源
|
||
orderRepo.Create(ctx, &order)
|
||
stockRepo.Decrease(ctx, productID, qty)
|
||
|
||
return nil
|
||
}
|
||
```
|
||
|
||
> [!warning] 生产环境避坑清单
|
||
>
|
||
> 1. **undo_log 表必须建**：`seata_undo_log` 是 Seata 自动创建的，用于存储前后镜像。务必保证这个表可用（通常和业务库在同一实例）
|
||
> 2. **不要混用本地事务和全局事务**：同一个方法里同时出现 `@Transactional` 和 `@GlobalTransactional` 会导致行为不可预测
|
||
> 3. **异常处理**：全局事务中抛出的异常会被 Seata 捕获并触发回滚，确保异常能正确向上传递
|
||
> 4. **性能考量**：全局锁虽然比 XA 短，但在高并发场景下仍然是瓶颈。**优先用 MQ 最终一致，实在做不到再上 AT**
|
||
> 5. **只支持部分数据库**：MySQL、PostgreSQL、Oracle 支持良好；TiDB 等 NewSQL 数据库兼容性有限
|
||
|
||
> [!tip] 选型建议
|
||
>
|
||
> AT 模式最适用的场景：**遗留系统微服务化改造**。当原有单体拆分成多个服务时，原有的 `@Transactional` 跨库调用突然失效，引入 AT 模式可以快速过渡——等业务稳定后再逐步迁移到 MQ 事件驱动架构。
|
||
|
||
## 补充保障：重试与死信队列
|
||
|
||
分布式系统中，**没有哪个组件永远可靠**。消息消费失败、网络闪断、下游超时——这些都不可避免。你需要一套完整的错误处理链路：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
MQ["消息队列"] --> C["消费者"]
|
||
C --> FAIL{消费成功}
|
||
FAIL -- 是 --> OK["正常结束"]
|
||
FAIL -- 否 --> RETRY{重试次数未满}
|
||
RETRY -- 是 --> DELAY["延迟重试<br/>指数退避"]
|
||
DELAY --> C
|
||
RETRY -- 否 --> DLQ["进入死信队列<br/>人工介入"]
|
||
|
||
DLQ --> ALERT["告警通知"]
|
||
DLQ --> REPLAY["手动重放或修复后补发"]
|
||
```
|
||
|
||
### 三种重试策略对比
|
||
|
||
| 策略 | 适用场景 | 示例 |
|
||
|------|---------|------|
|
||
| **立即重试** | 瞬时故障（连接池未就绪） | 等 100ms 再试 3 次 |
|
||
| **延迟重试** | 需要时间窗口等待恢复 | 1s → 2s → 4s → 8s |
|
||
| **定时任务补偿** | 批量漏掉的消息 | 每 5 分钟扫描 pending 表 |
|
||
|
||
### 死信队列 (DLQ) 设计
|
||
|
||
```go
|
||
// 消费者主循环：带重试和 DLQ 保护
|
||
func (c *consumer) Process(ctx context.Context, msg Message) error {
|
||
for attempt := 0; attempt < c.maxRetries; attempt++ {
|
||
err := c.handle(ctx, msg)
|
||
if err == nil {
|
||
return nil // 成功
|
||
}
|
||
|
||
if isRetryable(err) {
|
||
time.Sleep(time.Duration(attempt+1) * time.Second)
|
||
continue // 重试
|
||
}
|
||
|
||
// 非可重试错误，直接进 DLQ
|
||
return c.sendToDLQ(msg, err)
|
||
}
|
||
|
||
// 超过最大重试次数，进 DLQ
|
||
return c.sendToDLQ(msg, fmt.Errorf("exhausted %d retries", c.maxRetries))
|
||
}
|
||
```
|
||
|
||
> [!quote] 运维心态
|
||
>
|
||
> "一个没有死信队列的消息消费者，就像一辆没有备胎的车——任何一次不可预期的故障都会让你抛锚在路上。"
|
||
|
||
## 如何选择分布式事务方案？
|
||
|
||
> [!question]- 决策树
|
||
>
|
||
> 面对跨服务的数据一致性问题，你不需要每次都重新选型。按照下面的思路逐层判断即可：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
START["跨服务写操作"] --> Q1{核心资金或资产}
|
||
|
||
Q1 -- 是且要求强一致 --> TCC["TCC"]
|
||
Q1 -- 否 --> Q2{流程步数超过5}
|
||
|
||
Q2 -- 是长流程 --> SAGA["Saga"]
|
||
Q2 -- 否简单链路 --> Q3{容忍秒级延迟}
|
||
|
||
Q3 -- 可以 --> MQ["本地事务+MQ(Outbox)"]
|
||
Q3 -- 不可以毫秒级 --> TXMSG["RocketMQ事务消息"]
|
||
|
||
Q3 -- 无法接受最终一致 --> SEATA["Seata AT模式"]
|
||
|
||
TCC --> END["完成选择"]
|
||
SAGA --> END
|
||
MQ --> END
|
||
TXMSG --> END
|
||
SEATA --> WARNING["过渡方案,后续应迁移至事件驱动架构"]
|
||
WARNING --> END
|
||
|
||
style TCC fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
|
||
style SAGA fill:#fff3e0,stroke:#ff9800,stroke-width:2px
|
||
style MQ fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
|
||
style TXMSG fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
|
||
style SEATA fill:#fce4ec,stroke:#e91e63,stroke-width:2px
|
||
```
|
||
|
||
### 决策速查矩阵
|
||
|
||
| 你的业务特征 | 推荐方案 | 理由 |
|
||
|-------------|---------|------|
|
||
| 日订单量百万级，通知类场景 | Outbox + MQ | 性能最好，开发成本最低 |
|
||
| 支付/清算/账务核心链路 | TCC | 资源占用期间不允许其他事务修改 |
|
||
| 审批流、物流状态流转（多步） | Saga 编排式 | 流程清晰，补偿机制完备 |
|
||
| 已有 RocketMQ，对延迟敏感 | 事务消息 | 绕过 Outbox 轮询延迟 |
|
||
| 遗留系统快速拆分 | Seata AT | 零侵入，快速过渡 |
|
||
| 只需要"最终一致" | 本地事务 + MQ | 80% 的场景这就是答案 |
|
||
|
||
> [!tip] 黄金法则
|
||
>
|
||
> **"能用异步事件解决的，不要用两阶段提交；能本地事务 + MQ 解决的，不要上框架。"**
|
||
>
|
||
> 复杂度越高，出问题的概率越大。每一层抽象都引入了新的故障点——协调器挂了怎么办？补偿逻辑写错了怎么发现？回滚又失败了谁来做？保持简单是最好的工程纪律。
|
||
|
||
## 关联笔记
|
||
|
||
- [[03-数据一致性/01-数据库拆分]] — 数据库拆分是分布式事务的前提
|
||
- [[02-服务治理/06-容错模式]] — 熔断器和重试在分布式事务中的作用
|
||
- [[02-服务治理/05-服务间通信]] — 消息投递的一致性保障
|