Seata 框架

Seata 分布式事务全面解析

一、Seata 概述

Seata（Simple Extensible Autonomous Transaction Architecture）是阿里开源、现孵化于 Apache 的分布式事务解决方案，核心目标是让分布式事务的使用接近本地事务的低成本与高性能。

诞生背景：微服务拆分后，跨库 / 跨服务的数据一致性（如下单→扣库存→扣余额）成为痛点，Seata 提供一站式解决方案。
核心价值：支持 AT、TCC、SAGA、XA 四种事务模式；低侵入、高可用、易集成 Spring Cloud/Dubbo 等主流框架。

二、核心架构：三大组件

Seata 分布式事务由 TC、TM、RM 协同完成，三者通过 XID（全局事务 ID） 关联。

TC（Transaction Coordinator，事务协调器）
1. 独立部署的中间件（Seata Server），全局事务的 “大脑”。
2. 职责：管理全局事务状态、分配 XID、协调所有分支提交 / 回滚、维护全局锁。
TM（Transaction Manager，事务管理器）
1. 嵌入业务服务（如订单服务），全局事务的 “发起者”。
2. 职责：向 TC 开启 / 提交 / 回滚全局事务、传递 XID 到下游服务。
RM（Resource Manager，资源管理器）
1. 嵌入每个数据库 / 资源服务，分支事务的 “执行者”。
2. 职责：管理本地事务、向 TC 注册分支、上报分支状态、执行 TC 的提交 / 回滚指令。

三、四大事务模式详解

1. AT 模式（Automatic Transaction，默认）

无侵入、高性能、最常用，基于关系型数据库的本地 ACID 事务，通过 undo_log 自动补偿。

核心原理：改进版 2PC
- 一阶段（准备）：
  - RM 拦截 SQL，生成前镜像（修改前数据）与后镜像（修改后数据）。
  - 执行业务 SQL，将前镜像、后镜像、SQL 信息写入 undo_log，与业务数据在同一个本地事务提交。
  - 向 TC 申请全局锁，成功后释放本地锁与连接。
- 二阶段（提交 / 回滚）：
  - 全局提交：TC 通知所有 RM 异步删除 undo_log，瞬间完成。
  - 全局回滚：TC 通知所有 RM 通过 undo_log 生成反向 SQL，自动回滚数据。
特点：零代码侵入（仅需 @GlobalTransactional 注解）、性能高（一阶段提交释放锁）、支持 MySQL/Oracle 等；不支持非关系型数据库。
适用场景：电商下单、支付、库存扣减等90% 常规分布式事务场景。

2. TCC 模式（Try-Confirm-Cancel）

手动补偿、高灵活度，不依赖数据库事务，完全由业务代码定义三阶段逻辑。

核心原理：自定义 2PC
- Try（一阶段）：资源检查与预留（如冻结库存、冻结余额），不提交。
- Confirm（二阶段提交）：确认执行业务（如扣减冻结库存、扣减冻结余额）。
- Cancel（二阶段回滚）：取消并释放资源（如解冻库存、解冻余额）。
特点：无数据库依赖、灵活度高、可实现强一致性；需手动编写 Try/Confirm/Cancel 三套逻辑，侵入性高。
适用场景：非关系型数据库（Redis/Mongo）、跨系统 / 跨服务、对一致性要求极高的金融场景。

3. SAGA 模式

长事务、最终一致，解决跨服务 / 长流程的事务问题，无锁设计。

核心原理：长事务拆分
- 将长事务拆分为多个本地事务，每个事务提交后，若后续失败则反向补偿已成功的事务。
- 一阶段：正向执行业务（如创建订单→扣库存→扣余额）。
- 二阶段：失败时执行补偿事务（如恢复库存→恢复余额→取消订单）。
特点：无锁、性能高、适合长流程；仅保证最终一致，补偿逻辑复杂。
适用场景：旅行预订、订单履约、供应链等长流程、异步化、最终一致场景。

4. XA 模式

强一致、性能低，基于数据库原生 XA 接口的标准 2PC。

核心原理：标准 XA 协议
- 一阶段：所有 RM 执行本地事务并预提交（prepare），锁定资源，等待 TC 指令。
- 二阶段：TC 统一决策，全部提交或全部回滚。
特点：强一致（ACID）、无侵入；一阶段长期锁资源，性能差，易阻塞。
适用场景：银行转账、金融交易等强一致性要求极高、性能要求低的场景。

模式对比

模式	侵入性	一致性	性能	适用场景
AT	零	强	高	常规微服务、关系库
TCC	高	强	中	金融、非关系库
SAGA	中	最终	高	长流程、异步化
XA	零	强	低	核心金融、强一致

四、AT 模式实战（Spring Cloud）

1. 环境准备

依赖（Spring Boot）

<!-- Seata Starter -->
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>2.6.0</version>
</dependency>
<!-- 数据库驱动、MyBatis 等 -->

配置（application.yml）

seata:
  application-id: order-service
  tx-service-group: my-tx-group # 事务组名，与 TC 对应
  service:
    vgroup-mapping:
      my-tx-group: default # 映射到 TC 集群
  registry: # 注册中心（Nacos）
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: public
  config: # 配置中心（Nacos）
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848

数据库准备：每个业务库创建 undo_log 表（Seata 自动生成）。

2. 代码实现

TM（发起方：订单服务）：添加 @GlobalTransactional 注解

@Service
public class OrderServiceImpl implements OrderService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private ProductFeignClient productFeign;

    @Override
    @GlobalTransactional(rollbackFor = Exception.class) // 开启全局事务
    public void createOrder(Order order) {
        // 1. 本地事务：创建订单
        orderMapper.insert(order);
        // 2. 远程调用：扣减库存（传递 XID）
        productFeign.deductStock(order.getProductId(), order.getCount());
    }
}

RM（参与方：库存服务）：普通本地事务

@Service
public class ProductServiceImpl implements ProductService {
    @Autowired
    private ProductMapper productMapper;

    @Override
    public void deductStock(Long productId, Integer count) {
        // 本地事务：扣减库存
        productMapper.deductStock(productId, count);
    }
}

3. 执行流程（AT 模式）

TM（订单服务）向 TC 开启全局事务，获取 XID。
TM 执行本地事务（创建订单），RM 生成 undo_log 并提交，向 TC 注册分支。
TM 通过 Feign 调用库存服务，传递 XID。
RM（库存服务）获取 XID，注册分支，执行本地事务（扣库存），生成 undo_log 并提交。
TM 完成本地事务，向 TC 发起全局提交。
TC 通知所有 RM 异步删除 undo_log，全局事务完成。
AT 模式优缺点

优点
- 业务无侵入，只用一个注解；
- 一阶段直接提交，释放连接快、高性能；
- 自动 undo 补偿，不用手写 TCC 三套代码；
- 适配 SpringCloud、Dubbo 微服务生态。
缺点
- 只支持关系型数据库，不支持 Redis、Mongo；
- 有 undo_log 日志开销；
- 隔离级别不是串行化，极端并发下需业务兜底；
- 不支持跨分库分表复杂 SQL 特殊场景

五、高可用与部署

TC 集群部署：
1. 支持 Nacos/Eureka 注册中心，Nacos/Apollo 配置中心。
2. 集群模式下，TC 通过 raft 协议 选举主节点，保证高可用。
RM/TM 高可用：
1. 无状态设计，可水平扩展，通过注册中心发现 TC 集群。
持久化：
1. TC 全局事务日志持久化到 MySQL/File，宕机后可恢复。

六、常见问题与避坑

XID 传递失败：
1. 原因：Feign/HTTP 调用未传递 XID。
2. 解决：集成 Seata Feign 拦截器，自动传递 XID。
undo_log 膨胀：
1. 原因：二阶段提交后 undo_log 未及时清理。
2. 解决：开启 Seata 定时清理任务，或手动归档。
全局锁冲突：
1. 原因：多个事务同时修改同一数据，全局锁竞争。
2. 解决：优化业务，减少热点数据并发更新。
超时回滚：
1. 原因：分支事务执行超时，TC 触发回滚。
2. 解决：调整 seata.service.default.grouplist 超时时间。

七、总结

Seata 是微服务架构下分布式事务的首选框架，通过 AT、TCC、SAGA、XA 四种模式覆盖全场景，核心是 TC/TM/RM 协同 + XID 全局关联。AT 模式以零侵入、高性能成为常规场景的最佳实践，TCC/SAGA 则适配特殊场景。掌握 Seata 是解决微服务数据一致性问题的关键。

要不要我把以上内容浓缩成一份可直接使用的 Seata AT 模式配置清单 + 常见错误排查表？

posted @ 2026-05-02 00:06 ConfidentLiu 阅读(43) 评论(0) 收藏举报

刷新页面返回顶部

ConfidentLiu