299 lines
7.7 KiB
Markdown
299 lines
7.7 KiB
Markdown
# 分布式事务
|
||
|
||
## 问题
|
||
|
||
**背景**：在微服务架构中，我们经常遇到跨服务的数据一致性问题。
|
||
|
||
**问题**：
|
||
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 理论在实际场景中的权衡
|
||
- 能根据业务特点选择合适的一致性级别
|
||
- 有监控和告警体系，能快速定位分布式事务问题
|
||
|
||
**架构能力**：
|
||
- 能设计支持多种分布式事务模式的统一框架
|
||
- 考虑降级和熔断策略
|
||
- 有混沌工程实践（注入故障测试系统恢复能力）
|