# 分布式事务

## 问题

**背景**：在微服务架构中，我们经常遇到跨服务的数据一致性问题。

**问题**：
1. 请描述分布式事务的常见解决方案（至少 3 种）
2. 它们的优缺点和适用场景是什么？
3. 你在实际项目中是如何选择的？有没有遇到过什么坑？

---

## 标准答案

### 1. 常见解决方案

#### **方案一：2PC (Two-Phase Commit，两阶段提交)**

**原理**：
- 准备阶段：协调者询问所有参与者是否可以提交
- 提交阶段：如果所有参与者都回复"可以"，则发送提交指令；否则发送回滚指令

**优点**：
- 强一致性
- 原理简单，易于理解

**缺点**：
- **同步阻塞**：所有参与者在事务提交前都处于阻塞状态
- **单点故障**：协调者故障会导致参与者一直阻塞
- **数据不一致**：在第二阶段，部分节点收到提交指令，部分未收到

**适用场景**：
- 传统关系型数据库（XA 协议）
- 对一致性要求极高，可接受性能损耗的场景

**实际应用**：
- MySQL XA 事务
- Java JTA (Java Transaction API)

---

#### **方案二：3PC (Three-Phase Commit，三阶段提交)**

**原理**：
在 2PC 基础上增加 CanCommit 阶段：
1. CanCommit：协调者询问参与者是否可以执行
2. PreCommit：参与者预执行并回复
3. DoCommit：正式提交

**优点**：
- 相比 2PC 减少了阻塞时间
- 引入超时机制，参与者可以自动决策

**缺点**：
- 仍然存在数据不一致风险
- 协议更复杂，实现成本高
- 性能提升有限

**适用场景**：
- 很少在实际生产中使用，更多是理论意义

---

#### **方案三：TCC (Try-Confirm-Cancel，补偿事务)**

**原理**：
- **Try 阶段**：尝试执行业务，完成资源的检查和预留
- **Confirm 阶段**：确认执行业务，使用 Try 阶段预留的资源
- **Cancel 阶段**：取消执行业务，释放 Try 阶段预留的资源

**代码示例**：
```java
// Try 阶段
public boolean try() {
    // 检查账户余额
    // 冻结相应金额（预留资源）
    // return true/false
}

// Confirm 阶段
public boolean confirm() {
    // 扣除冻结金额
    // 真正完成转账
}

// Cancel 阶段
public boolean cancel() {
    // 释放冻结金额
    // 恢复原始状态
}
```

**优点**：
- **最终一致性**
- 性能较好，相比 2PC 没有长时间锁资源
- 业务可控性强

**缺点**：
- **代码侵入性强**：每个业务都需要写三个接口
- **开发成本高**：需要考虑各种异常情况
- **容易遗漏**：Cancel 接口如果实现不完整会导致资源泄露

**适用场景**：
- 对性能有一定要求
- 业务逻辑清晰，可以拆分成 Try/Confirm/Cancel
- 高并发场景

**实际应用**：
- 阿里巴巴 Seata 的 TCC 模式
- 支付系统、订单系统

---

#### **方案四：本地消息表（异步确保）**

**原理**：
1. 上游服务在同一本地事务中：
   - 完成业务操作
   - 存储一条消息到本地消息表（状态为"待发送"）
2. 定时任务扫描消息表，发送消息到 MQ
3. 下游服务消费 MQ，执行业务逻辑
4. 下游服务成功后通知上游更新消息状态

**优点**：
- 实现简单
- 可靠性高（消息持久化）
- 支持重试

**缺点**：
- 需要维护本地消息表
- 定时任务有延迟
- 需要处理消息重复消费（幂等性）

**适用场景**：
- 可以接受最终一致性
- 对实时性要求不高
- 高并发场景

**实际应用**：
- 支付宝到账通知
- 订单创建后的物流通知

---

#### **方案五：MQ 事务消息（RocketMQ 方案）**

**原理**：
1. 发送半消息（Half Message）到 MQ（消息对消费者不可见）
2. 执行本地事务
3. 提交/回滚消息：
   - 本地事务成功 → 提交消息（消息对消费者可见）
   - 本地事务失败 → 删除消息
4. MQ 提供反查机制：如果长时间未收到确认，主动查询业务方事务状态

**优点**：
- 解耦性强
- 性能好
- 支持大规模分布式事务

**缺点**：
- 依赖特定 MQ（如 RocketMQ）
- 需要实现反查接口
- 消息可能有延迟

**适用场景**：
- 高并发、大规模分布式系统
- 可以接受最终一致性
- 需要解耦上下游服务

**实际应用**：
- RocketMQ 事务消息
- 双11 大促场景

---

#### **方案六：Saga 模式**

**原理**：
将长事务拆分为多个本地短事务，每个短事务都有对应的补偿操作：
- 正向操作：T1, T2, T3, ..., Tn
- 补偿操作：Cn, ..., C3, C2, C1（反向补偿）

**示例**：
```
预订行程 Saga：
1. 预订航班 (T1)
2. 预订酒店 (T2)
3. 预订租车 (T3)

如果 T2 失败：
1. 取消航班 (C1)
2. 返回失败给用户
```

**优点**：
- 适合长事务、业务流程复杂的场景
- 最终一致性
- 可以跨多个服务

**缺点**：
- 需要为每个操作设计补偿逻辑
- 补偿操作可能失败，需要处理
- 无法保证隔离性（脏读问题）

**适用场景**：
- 业务流程长、涉及多个服务
- 旅行预订、电商下单
- 微服务编排

**实际应用**：
- Apache ServiceComb Saga
- Netflix Conductor

---

### 2. 方案对比总结

| 方案 | 一致性 | 性能 | 复杂度 | 适用场景 |
|------|--------|------|--------|----------|
| 2PC | 强一致性 | 低（同步阻塞） | 低 | 传统数据库 |
| 3PC | 强一致性 | 中 | 中 | 很少使用 |
| TCC | 最终一致性 | 高 | 高（业务侵入） | 高并发、强业务控制 |
| 本地消息表 | 最终一致性 | 中 | 低 | 高可靠性、可接受延迟 |
| MQ 事务消息 | 最终一致性 | 高 | 中 | 大规模、高并发、解耦 |
| Saga | 最终一致性 | 高 | 高（补偿逻辑） | 长事务、业务编排 |

---

### 3. 实际项目选择建议

**选择决策树**：
```
是否需要强一致性？
├─ 是 → 2PC（XA 事务）
└─ 否 → 最终一致性
    │
    ├─ 业务可以拆分为 Try/Confirm/Cancel？
    │   ├─ 是 → TCC（高并发、强控制）
    │   └─ 否 → 继续判断
    │
    ├─ 使用 RocketMQ？
    │   ├─ 是 → MQ 事务消息
    │   └─ 否 → 继续判断
    │
    ├─ 业务流程长、涉及多服务？
    │   ├─ 是 → Saga
    │   └─ 否 → 本地消息表
```

**常见坑和注意事项**：

1. **幂等性问题**（所有方案都需要考虑）
   - 重复请求导致的重复扣款、重复发货
   - 解决：使用唯一业务 ID、Redis 分布式锁

2. **空补偿问题**（TCC）
   ```java
   // Cancel 被调用时，Try 可能还没执行
   public void cancel() {
       // 需要检查是否有冻结记录
       if (没有冻结记录) {
           return; // 空补偿，直接返回
       }
       // 执行取消逻辑
   }
   ```

3. **悬挂问题**（TCC）
   - Confirm 比 Cancel 先到
   - 解决：记录事务状态，拒绝后续操作

4. **消息丢失**（MQ 方案）
   - 网络抖动导致消息丢失
   - 解决：ACK 机制 + 重试 + 死信队列

5. **资源锁定时间**（2PC）
   - 长时间锁资源导致性能下降
   - 解决：控制事务规模，拆分大事务

---

### 4. 阿里 P7 加分项

**实际项目经验**：
- 设计并实现过千万级用户的分布式事务系统
- 处理过分布式事务的性能瓶颈（如连接池优化、并发度控制）
- 有 TCC/Saga 的踩坑经验和解决方案

**深度理解**：
- 理解 CAP 理论在实际场景中的权衡
- 能根据业务特点选择合适的一致性级别
- 有监控和告警体系，能快速定位分布式事务问题

**架构能力**：
- 能设计支持多种分布式事务模式的统一框架
- 考虑降级和熔断策略
- 有混沌工程实践（注入故障测试系统恢复能力）