202524 | 分布式事务

分布式事务（Distributed Transaction）

分布式事务是指跨多个数据库、服务或系统节点的事务操作，要求所有参与方要么全部成功提交，要么全部回滚，保证数据一致性。

1. 为什么需要分布式事务？

在单体应用中，事务可以通过数据库的 ACID（原子性、一致性、隔离性、持久性）保证。但在微服务或分布式系统中：

• 数据分散：不同服务使用不同的数据库（如订单库、库存库、支付库）。
• 网络不可靠：跨服务调用可能失败（如支付成功但库存扣减失败）。
• 业务复杂：多个服务需要协同完成一个业务（如电商下单 → 支付 → 库存扣减）。

示例场景：

• 问题：如果支付成功但库存扣减失败，数据不一致！

2. 分布式事务的挑战（CAP理论）

在分布式系统中，无法同时满足：

• 一致性（Consistency）：所有节点数据一致。
• 可用性（Availability）：服务总能响应。
• 分区容错性（Partition Tolerance）：网络分区时仍能运行。

分布式系统必须选择 CP（强一致性）或 AP（高可用性）。

分布式事务的解决方案

分布式事务解决方案终极详解

一、核心问题与挑战

在分布式系统中，事务需要跨多个服务或数据库，面临三大核心问题：

1. 原子性破坏：部分操作成功，部分失败
2. 数据不一致：网络延迟或故障导致状态不一致
3. 性能瓶颈：同步阻塞降低系统吞吐量

二、强一致性方案详解

1. 2PC（两阶段提交）

核心思想：通过协调者统一调度

关键问题：

• 同步阻塞：所有参与者在准备阶段锁定资源
• 单点故障：协调者宕机导致系统僵死
• 数据不一致：网络分区时可能部分提交

优化方案：

2. Seata AT模式

架构原理：

执行流程：

1. 一阶段：
   • 解析业务SQL生成前后镜像
   • 本地提交并上报TC
2. 二阶段：
   • 成功：异步删除快照
   • 失败：用前镜像回滚

全局锁机制：

三、最终一致性方案详解

1. TCC模式

三阶段操作：

异常处理设计：

注意事项：

• 必须实现幂等性
• 需要空回滚和防悬挂处理
• 业务侵入性强

2. Saga模式

两种实现方式对比：

事件编排示例：

补偿机制设计：

3. 本地消息表

完整架构：

可靠性保障：

四、方案选型矩阵**

Seata

一、Seata 核心架构

核心组件：

1. TC (Transaction Coordinator)
   • 事务协调器（独立部署）
   • 维护全局事务状态，驱动分支事务提交/回滚
2. TM (Transaction Manager)
   • 集成在应用中
   • 定义事务边界，发起全局提交/回滚
3. RM (Resource Manager)
   • 管理分支事务，向TC注册分支状态
   • 生成SQL镜像，实现数据回滚

二、Seata 的四种模式对比

三、AT 模式详解（默认模式）

1. 执行流程

2. 核心机制

• 全局锁：防止脏写
• undo_log表：

  CREATE TABLE `undo_log` (
    `id` bigint(20) NOT NULL AUTO_INCREMENT,
    `branch_id` bigint(20) NOT NULL,
    `xid` varchar(100) NOT NULL,
    `context` varchar(128) NOT NULL,
    `rollback_info` longblob NOT NULL,
    `log_status` int(11) NOT NULL,
    PRIMARY KEY (`id`)
  );
  

3. 适用场景

• 80%的常规分布式事务场景
• 支持MySQL、Oracle等主流数据库

四、TCC 模式详解

1. 三阶段操作

2. 异常处理设计

3. 注意事项

• 必须实现幂等性
• 需要处理空回滚和防悬挂
• 典型业务代码：

  @LocalTCC
  public interface OrderTccService {
      @TwoPhaseBusinessAction(name = "createOrder", commitMethod = "confirm", rollbackMethod = "cancel")
      boolean tryCreateOrder(Order order);
      
      boolean confirm(Order order);
      
      boolean cancel(Order order);
  }
  

五、Saga 模式详解

1. 状态机设计

2. 补偿机制

3. 适用场景

• 跨多服务的业务流程（如电商下单→支付→物流）
• 每个步骤都需要显式定义补偿操作

六、XA 模式详解

1. 传统XA协议增强

2. 特点

• 完全兼容传统XA协议
• 需要数据库支持XA（MySQL 5.7+）

七、Seata 生产实践

1. 部署架构

2. 高可用配置

# registry.conf
registry {
  type = "nacos"
  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    cluster = "default"
  }
}

store {
  mode = "db"
  db {
    datasource = "druid"
    url = "jdbc:mysql://127.0.0.1:3306/seata"
    user = "root"
    password = "123456"
  }
}

3. 性能调优

# 调整TC处理线程数
server.max.commit.retry.timeout=60000
server.max.rollback.retry.timeout=60000
store.db.global.table=global_table
store.db.branch.table=branch_table

八、Seata 与同类方案对比

九、最佳实践建议

1. 常规业务：优先使用AT模式
2. 高并发场景：TCC + 异步Confirm
3. 长业务流程：Saga状态机 + 可视化监控
4. 传统系统改造：XA模式

如果需要 具体场景的完整代码示例（如电商下单的AT模式实现），可以告诉我具体需求！