编辑“︁分布式事务”︁（章节）

= 分布式事务 =

'''分布式事务'''是指跨越多个独立的计算机系统或数据库的事务操作，这些系统可能位于不同的物理位置，甚至由不同的组织管理。分布式事务的核心目标是确保所有参与的系统要么全部成功提交事务，要么全部回滚，从而保持数据的一致性和完整性。

== 简介 ==

在传统的单机数据库中，事务的ACID（原子性、一致性、隔离性、持久性）特性由数据库管理系统（DBMS）直接保证。但在分布式环境中，由于数据分布在多个节点上，事务管理变得更加复杂。分布式事务需要协调多个独立的资源管理器（如数据库、消息队列等），以确保跨系统操作的原子性和一致性。

分布式事务的典型应用场景包括：
* 跨银行转账（涉及多个银行系统）
* 电商订单处理（涉及库存、支付、物流等多个服务）
* 微服务架构下的数据一致性保证

== 分布式事务模型 ==

=== 两阶段提交（2PC） ===

两阶段提交（Two-Phase Commit, 2PC）是最经典的分布式事务协议，分为两个阶段：

1. '''准备阶段'''：协调者询问所有参与者是否可以提交事务。
2. '''提交阶段'''：如果所有参与者都同意，协调者通知所有参与者提交事务；否则，通知回滚。

<mermaid>
sequenceDiagram
    participant C as Coordinator
    participant P1 as Participant 1
    participant P2 as Participant 2

    C->>P1: Prepare
    C->>P2: Prepare
    P1-->>C: Yes/No
    P2-->>C: Yes/No
    alt All participants agree
        C->>P1: Commit
        C->>P2: Commit
    else Any participant disagrees
        C->>P1: Rollback
        C->>P2: Rollback
    end
</mermaid>

==== 代码示例 ====

以下是一个简化的2PC实现伪代码：

<syntaxhighlight lang="python">
class Coordinator:
    def execute_transaction(self):
        participants = [Participant1(), Participant2()]
        
        # Phase 1: Prepare
        all_agreed = True
        for p in participants:
            if not p.prepare():
                all_agreed = False
                break
        
        # Phase 2: Commit or Rollback
        for p in participants:
            if all_agreed:
                p.commit()
            else:
                p.rollback()

class Participant1:
    def prepare(self):
        # 检查资源是否可用
        return True  # 或 False
    
    def commit(self):
        # 执行提交
        pass
    
    def rollback(self):
        # 执行回滚
        pass
</syntaxhighlight>

=== 三阶段提交（3PC） ===

三阶段提交（3PC）是对2PC的改进，增加了超时机制和预提交阶段，减少了阻塞问题：

1. '''CanCommit阶段'''：协调者询问参与者是否可以提交
2. '''PreCommit阶段'''：协调者发送预提交命令
3. '''DoCommit阶段'''：协调者发送最终提交命令

== 分布式事务协议 ==

=== XA规范 ===

XA是由X/Open组织提出的分布式事务处理规范，定义了全局事务管理器（TM）与本地资源管理器（RM）之间的接口。

<syntaxhighlight lang="java">
// Java XA示例
import javax.transaction.xa.*;

XAResource xaRes1, xaRes2;
Xid xid = new MyXid();

try {
    xaRes1.start(xid, XAResource.TMNOFLAGS);
    // 执行操作1...
    xaRes1.end(xid, XAResource.TMSUCCESS);

    xaRes2.start(xid, XAResource.TMNOFLAGS);
    // 执行操作2...
    xaRes2.end(xid, XAResource.TMSUCCESS);

    int ret = xaRes1.prepare(xid);
    if (ret == XAResource.XA_OK) {
        xaRes1.commit(xid, false);
        xaRes2.commit(xid, false);
    }
} catch (XAException e) {
    // 处理异常
    xaRes1.rollback(xid);
    xaRes2.rollback(xid);
}
</syntaxhighlight>

=== TCC模式 ===

TCC（Try-Confirm-Cancel）是一种补偿型事务模式：
1. '''Try'''：预留资源
2. '''Confirm'''：确认执行业务
3. '''Cancel'''：取消业务并释放资源

== 实际案例 ==

=== 电商订单系统 ===

考虑一个电商系统，创建订单涉及：
1. 库存服务（减少库存）
2. 支付服务（扣款）
3. 订单服务（创建订单记录）

使用分布式事务可以确保：
* 要么所有操作成功（库存减少、扣款成功、订单创建）
* 要么所有操作回滚（库存不变、金额不变、无订单记录）

=== 跨行转账 ===

银行A向银行B转账100元：
1. 银行A系统减少100元
2. 银行B系统增加100元

分布式事务确保这两个操作要么都成功，要么都失败，避免出现A已扣款但B未到账的情况。

== 挑战与解决方案 ==

{| class="wikitable"
|-
! 挑战 !! 解决方案
|-
| 网络分区 || 使用超时机制、最终一致性
|-
| 性能开销 || 优化协议（如3PC）、异步提交
|-
| 单点故障 || 使用高可用协调者、Paxos/Raft协议
|-
| 数据不一致 || 定期对账、补偿事务
|}

== 数学基础 ==

分布式事务的可用性可以用CAP定理描述：

<math>
\text{对于一个分布式系统，最多只能同时满足以下两项：}
\begin{cases}
\text{一致性（Consistency）} \\
\text{可用性（Availability）} \\
\text{分区容错性（Partition tolerance）}
\end{cases}
</math>

BASE理论（Basically Available, Soft state, Eventually consistent）是CAP的实践延伸。

== 总结 ==

分布式事务是构建可靠分布式系统的关键技术，虽然实现复杂，但通过合适的协议和模式（如2PC、3PC、TCC等）可以在不同场景下保证数据一致性。开发者需要根据具体业务需求选择合适的事务方案，权衡一致性、可用性和性能之间的关系。

[[Category:计算机科学]]
[[Category:数据库与信息系统]]
[[Category:数据库事务与并发控制]]