202524 | 分布式事务

news2025/5/28 11:11:24

分布式事务（Distributed Transaction）

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

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

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

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

示例场景：

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

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

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

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

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

分布式事务的解决方案

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

一、核心问题与挑战

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

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

二、强一致性方案详解

1. 2PC（两阶段提交）

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

关键问题：

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

优化方案：

2. Seata AT模式

架构原理：

执行流程：

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

全局锁机制：

三、最终一致性方案详解

1. TCC模式

三阶段操作：

异常处理设计：

注意事项：

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

2. Saga模式

两种实现方式对比：

事件编排示例：

补偿机制设计：

3. 本地消息表

完整架构：

可靠性保障：

四、方案选型矩阵**

维度	2PC	TCC	Saga	本地消息表	Seata AT
一致性	强一致	最终一致	最终一致	最终一致	强一致
性能	低	高	中	中	中高
侵入性	无	高	中	低	低
复杂度	低	高	中	低	中
适用场景	金融支付	电商秒杀	长事务	日志同步	微服务

Seata

一、Seata 核心架构

核心组件：

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

二、Seata 的四种模式对比

模式	一致性	性能	侵入性	适用场景
AT	强一致	高	低	常规微服务
TCC	最终	极高	高	高并发（如秒杀）
Saga	最终	中	中	长事务流程
XA	强一致	低	无	传统数据库兼容

三、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 与同类方案对比

特性	Seata	DTX	ShardingSphere
AT模式	✔️	✖️	✖️
TCC支持	✔️	✔️	✖️
Saga支持	✔️	✖️	✔️
XA支持	✔️	✔️	✔️
无侵入	AT/XA	✖️	✖️