分布式事务:修订间差异
外观
Page creation by admin bot |
Page update by admin bot 标签:已被回退 |
||
第1行: | 第1行: | ||
= 分布式事务 = | == 分布式事务 == | ||
'''分布式事务''' | '''分布式事务'''是指跨越多个独立计算机节点或服务的事务操作,这些操作要么全部成功执行,要么全部失败回滚。在分布式系统中,由于数据和服务分散在不同的物理节点上,如何保证事务的原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)成为关键挑战。 | ||
== | === 核心概念 === | ||
分布式事务的核心目标是确保跨多个节点的操作满足ACID特性。常见的实现方式包括: | |||
* '''两阶段提交(2PC, Two-Phase Commit)''' | |||
* '''三阶段提交(3PC, Three-Phase Commit)''' | |||
* '''补偿事务(Saga模式)''' | |||
* | * '''TCC(Try-Confirm-Cancel)''' | ||
* | |||
* | |||
=== 两阶段提交(2PC) === | === 两阶段提交(2PC) === | ||
2PC是最经典的分布式事务协议,分为两个阶段: | |||
1. '''准备阶段''':协调者询问所有参与者是否可以提交事务。 | 1. '''准备阶段''':协调者询问所有参与者是否可以提交事务。 | ||
2. '''提交阶段''' | 2. '''提交阶段''':如果所有参与者同意,协调者发送提交命令;否则发送回滚命令。 | ||
==== 代码示例 ==== | ==== 代码示例 ==== | ||
以下是一个简化的2PC协调者伪代码: | |||
<syntaxhighlight lang="python"> | <syntaxhighlight lang="python"> | ||
class Coordinator: | class Coordinator: | ||
def execute_transaction(self): | def execute_transaction(self): | ||
participants = [ | participants = [ParticipantA(), ParticipantB()] | ||
# | # 阶段1:准备 | ||
all_prepared = True | |||
for p in participants: | for p in participants: | ||
if not p.prepare(): | if not p.prepare(): | ||
all_prepared = False | |||
break | break | ||
# | # 阶段2:提交或回滚 | ||
if all_prepared: | |||
for p in participants: | |||
p.commit() | p.commit() | ||
else: | |||
for p in participants: | |||
p.rollback() | p.rollback() | ||
</syntaxhighlight> | </syntaxhighlight> | ||
=== 三阶段提交(3PC) === | === 三阶段提交(3PC) === | ||
3PC在2PC基础上增加了超时机制和预提交阶段,解决了2PC的阻塞问题。三个阶段为: | |||
1. '''CanCommit''':询问参与者是否具备执行条件 | |||
2. '''PreCommit''':预提交并锁定资源 | |||
3. '''DoCommit''':最终提交 | |||
=== Saga模式 === | |||
Saga通过将大事务拆分为多个本地事务,并为每个本地事务设计补偿操作来实现最终一致性。例如电商下单流程: | |||
<mermaid> | |||
sequenceDiagram | |||
participant User | |||
participant OrderService | |||
participant PaymentService | |||
participant InventoryService | |||
User->>OrderService: 创建订单 | |||
OrderService->>PaymentService: 扣款 | |||
PaymentService->>InventoryService: 扣减库存 | |||
alt 成功 | |||
InventoryService-->>OrderService: 确认 | |||
OrderService-->>User: 下单成功 | |||
else 失败 | |||
InventoryService-->>PaymentService: 补偿 | |||
PaymentService-->>OrderService: 退款 | |||
OrderService-->>User: 下单失败 | |||
end | |||
</mermaid> | |||
== | === TCC模式 === | ||
TCC(Try-Confirm-Cancel)要求每个服务实现三个接口: | |||
1. '''Try''':预留资源 | |||
2. '''Confirm''':确认操作 | |||
3. '''Cancel''':取消预留 | |||
==== 实际案例 ==== | |||
以转账为例: | |||
<syntaxhighlight lang="java"> | <syntaxhighlight lang="java"> | ||
// | // Try阶段 | ||
accountService.freezeAmount(fromAccount, amount); | |||
accountService.freezeAmount(toAccount, amount); | |||
// Confirm阶段 | |||
accountService.debit(fromAccount, amount); | |||
accountService.credit(toAccount, amount); | |||
// Cancel阶段 | |||
accountService.unfreeze(fromAccount, amount); | |||
accountService.unfreeze(toAccount, amount); | |||
</syntaxhighlight> | </syntaxhighlight> | ||
=== | === 数学基础 === | ||
分布式事务的可用性可以通过CAP定理理解: | |||
= | |||
<math> | <math> | ||
\text{ | \text{分布式系统} \Rightarrow \text{最多满足其中两项:} | ||
\begin{cases} | \begin{cases} | ||
\text{一致性(Consistency)} \\ | \text{一致性(Consistency)} \\ | ||
第175行: | 第100行: | ||
</math> | </math> | ||
=== 性能考量 === | |||
* 2PC吞吐量公式:<math>Throughput = \frac{N}{T_{prepare} + T_{commit}}</math> | |||
* 网络延迟对事务成功率的影响:<math>P_{success} = e^{-\lambda T_{timeout}}</math> | |||
=== 最佳实践 === | |||
1. 尽量设计无状态服务 | |||
2. 对非关键路径采用最终一致性 | |||
3. 实现幂等接口防止重复操作 | |||
4. 设置合理的事务超时时间 | |||
=== 常见问题 === | |||
* '''Q: 如何选择合适的事务模式?''' | |||
A: 强一致性场景用2PC/3PC,长事务用Saga,高并发用TCC。 | |||
* '''Q: 网络分区时如何处理?''' | |||
A: 通过心跳检测和超时机制,进入补偿流程。 | |||
== | === 扩展阅读 === | ||
* 分布式锁的实现 | |||
* 消息队列的事务消息 | |||
* 分布式ID生成方案 | |||
本文涵盖了分布式事务的核心概念、实现模式和实战案例,适合从入门到进阶的学习路径。通过理论结合代码示例,读者可以全面理解这一关键的系统设计主题。 | |||
[[Category:计算机科学]] | [[Category:计算机科学]] | ||
[[Category: | [[Category:面试技巧]] | ||
[[Category: | [[Category:系统设计]] |
2025年5月12日 (一) 00:24的版本
分布式事务
分布式事务是指跨越多个独立计算机节点或服务的事务操作,这些操作要么全部成功执行,要么全部失败回滚。在分布式系统中,由于数据和服务分散在不同的物理节点上,如何保证事务的原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)成为关键挑战。
核心概念
分布式事务的核心目标是确保跨多个节点的操作满足ACID特性。常见的实现方式包括:
- 两阶段提交(2PC, Two-Phase Commit)
- 三阶段提交(3PC, Three-Phase Commit)
- 补偿事务(Saga模式)
- TCC(Try-Confirm-Cancel)
两阶段提交(2PC)
2PC是最经典的分布式事务协议,分为两个阶段: 1. 准备阶段:协调者询问所有参与者是否可以提交事务。 2. 提交阶段:如果所有参与者同意,协调者发送提交命令;否则发送回滚命令。
代码示例
以下是一个简化的2PC协调者伪代码:
class Coordinator:
def execute_transaction(self):
participants = [ParticipantA(), ParticipantB()]
# 阶段1:准备
all_prepared = True
for p in participants:
if not p.prepare():
all_prepared = False
break
# 阶段2:提交或回滚
if all_prepared:
for p in participants:
p.commit()
else:
for p in participants:
p.rollback()
三阶段提交(3PC)
3PC在2PC基础上增加了超时机制和预提交阶段,解决了2PC的阻塞问题。三个阶段为: 1. CanCommit:询问参与者是否具备执行条件 2. PreCommit:预提交并锁定资源 3. DoCommit:最终提交
Saga模式
Saga通过将大事务拆分为多个本地事务,并为每个本地事务设计补偿操作来实现最终一致性。例如电商下单流程:
TCC模式
TCC(Try-Confirm-Cancel)要求每个服务实现三个接口: 1. Try:预留资源 2. Confirm:确认操作 3. Cancel:取消预留
实际案例
以转账为例:
// Try阶段
accountService.freezeAmount(fromAccount, amount);
accountService.freezeAmount(toAccount, amount);
// Confirm阶段
accountService.debit(fromAccount, amount);
accountService.credit(toAccount, amount);
// Cancel阶段
accountService.unfreeze(fromAccount, amount);
accountService.unfreeze(toAccount, amount);
数学基础
分布式事务的可用性可以通过CAP定理理解:
性能考量
- 2PC吞吐量公式:
- 网络延迟对事务成功率的影响:
最佳实践
1. 尽量设计无状态服务 2. 对非关键路径采用最终一致性 3. 实现幂等接口防止重复操作 4. 设置合理的事务超时时间
常见问题
- Q: 如何选择合适的事务模式?
A: 强一致性场景用2PC/3PC,长事务用Saga,高并发用TCC。
- Q: 网络分区时如何处理?
A: 通过心跳检测和超时机制,进入补偿流程。
扩展阅读
- 分布式锁的实现
- 消息队列的事务消息
- 分布式ID生成方案
本文涵盖了分布式事务的核心概念、实现模式和实战案例,适合从入门到进阶的学习路径。通过理论结合代码示例,读者可以全面理解这一关键的系统设计主题。