《Seata从入门到实战》第一章：Seata核心概念与架构

本期内容为自己总结归档，欢迎评论区指正~

第一章：Seata核心概念与架构概览

第二章：AT 模式详解

第三章：TCC模式详解

第四章：Saga模式详解

第五章：XA模式详解

第六章：seata从部署到集成实战&避坑指南

第七章：seata总结

点赞关注哦~

第一章：Seata核心概念与架构概览

1.1 分布式事务的核心挑战与Seata的解决方案

在微服务架构成为主流的今天，一个业务操作经常需要跨越多个服务边界，每个服务都可能操作独立的数据库。传统的单体应用依靠数据库的ACID事务保证数据一致性，但这种机制在服务被拆分后完全失效。这引出了分布式系统领域的经典难题——如何在分布式环境下保证跨服务、跨数据库的数据操作具有一致性。

分布式事务面临的核心挑战主要体现在CAP定理的约束下：

1. 原子性（Atomicity）难以保障：在分布式环境中，一个全局事务由多个本地事务组成。由于网络分区、节点故障等不可控因素，无法保证所有参与节点在同一时刻达成一致提交或回滚的决定。

2. 隔离性（Isolation）实现复杂：传统数据库通过锁机制实现隔离级别，但在分布式场景下，跨服务的读写操作可能产生难以察觉的脏读、不可重复读和幻读问题，且分布式锁的引入又会严重影响系统性能。

3. 协调成本高昂：需要一个可靠的协调者来管理所有参与者的状态，协调者本身的可用性、性能瓶颈都会成为系统的单点故障风险。

业界常见的分布式事务解决方案如两阶段提交（2PC）、三阶段提交（3PC）、消息队列最终一致性等，各自存在明显的局限性。正是在这样的背景下，阿里巴巴开源了Seata（Simple Extensible Autonomous Transaction Architecture），旨在提供一站式、高性能、易集成的分布式事务解决方案。

Seata的核心设计哲学是：像使用本地事务一样使用分布式事务。它通过对业务极低的侵入性，将复杂的分布式事务问题封装在框架内部，让开发者聚焦业务逻辑本身。

1.2 Seata的演进历程与核心设计思想

Seata的发展历程体现了对分布式事务问题理解的不断深化：

1. 第一阶段：AT模式主导期（2019年初）

   • 基于两阶段提交思想的增强版，通过全局锁和回滚日志实现自动补偿

   • 优势：对业务代码零侵入，接入成本极低

   • 局限：对数据库操作有约束，全局锁可能成为性能瓶颈

2. 第二阶段：多模式并存期（2019-2020）

   • 引入TCC、Saga、XA模式，形成完整的分布式事务解决方案矩阵

   • 针对不同业务场景提供差异化选择

   • 架构上进行解耦，TC（事务协调器）可独立部署

3. 第三阶段：高性能与云原生（2021至今）

   • 支持高可用集群部署

   • 优化全局锁竞争，减少性能损耗

   • 增强与云原生组件的集成能力

Seata的核心设计思想可以概括为三个关键词：

1. 解耦：将事务协调逻辑从业务服务中彻底分离，通过独立的TC组件集中管理事务状态。

2. 分层：架构上清晰划分为协调层（TC）和参与层（TM/RM），各层职责单一。

3. 可插拔：支持多种事务模式，可根据业务特点灵活选择和组合。

这种设计使得Seata既能保持框架的简洁性，又能应对复杂的业务场景需求。

1.3 Seata的核心组件与职责划分

Seata的架构采用经典的协调者-参与者模式，但进行了重要改进。整个系统由三个核心组件构成，它们各司其职，协同完成分布式事务管理。

1.3.1 TC（Transaction Coordinator）- 事务协调器

TC是Seata架构的大脑和中枢，负责协调分布式事务的最终状态。它的核心职责包括：

1. 全局事务管理：

   • 维护全局事务的生命周期状态（BEGIN, COMMITTING, COMMITTED, ROLLBACKING, ROLLBACKED）

   • 生成全局唯一的XID（全局事务ID）并传播到整个调用链

   • 接收TM的全局事务提交/回滚指令，驱动所有分支事务完成两阶段提交或回滚

2. 分支事务注册与状态追踪：

   • 接收RM的分支事务注册请求，建立全局事务与分支事务的映射关系

   • 监控所有分支事务的执行状态，为全局决策提供依据

3. 全局锁管理（针对AT模式）：

   • 维护全局行锁，防止多个分布式事务同时修改同一数据

   • 处理锁的获取、释放和超时机制

   • 解决分布式环境下的写-写冲突问题

TC在设计上采用无状态架构，所有事务状态都持久化存储在数据库中（如MySQL）。这使得TC可以轻松实现水平扩展和高可用部署，通过集群化避免单点故障。

1.3.2 TM（Transaction Manager）- 事务管理器

TM是分布式事务的发起者和边界定义者，通常嵌入在业务服务中。它的主要职责包括：

1. 事务边界定义：

   • 通过@GlobalTransactional注解或API调用声明一个全局事务的开始

   • 确定哪些操作需要纳入同一个分布式事务的管辖范围

2. 全局事务控制：

   • 向TC发起全局事务开始请求，获取XID

   • 根据业务执行结果，决定向TC发起全局提交或回滚请求

   • 处理超时和异常情况，确保事务的最终一致性

3. 事务上下文管理：

   • 将XID注入到当前线程上下文

   • 确保XID在服务调用链中正确传递

   • 在事务结束时清理上下文资源

TM的设计体现了Seata对业务低侵入的理念。开发者只需在方法上添加一个注解，框架就会自动处理复杂的分布式事务逻辑。

1.3.3 RM（Resource Manager）- 资源管理器

RM是分布式事务的最终执行者，负责与底层资源（主要是数据库）交互。每个参与分布式事务的微服务都会有一个RM实例。RM的核心职责包括：

1. 分支事务管理：

   • 向TC注册分支事务，建立与全局事务的关联

   • 执行业务SQL，生成对应的回滚日志（针对AT模式）

   • 向TC报告分支事务的执行状态

2. 本地资源协调：

   • 管理数据库连接，将XID与数据库连接绑定

   • 在AT模式下，拦截SQL执行，生成前后镜像数据

   • 在TCC模式下，调用Try、Confirm、Cancel方法

3. 事务指令响应：

   • 接收TC发来的提交或回滚指令

   • 执行二阶段操作：提交时删除回滚日志，回滚时利用回滚日志进行补偿

   • 释放本地持有的资源锁

RM通过数据源代理机制实现对数据库操作的透明拦截。这种设计使得业务代码无需感知分布式事务的存在，大大降低了接入成本。

1.4 全局事务ID（XID）的生成与传递机制

XID是Seata分布式事务体系的唯一标识和串联纽带，它的正确生成和传递是保证事务一致性的基础。

1.4.1 XID的生成规则

Seata的XID采用三段式结构，格式为：IP地址:端口:全局事务ID

// 示例XID：192.168.1.100:8091:1234567890 // 组成解析： // - 192.168.1.100:8091：TC服务器的地址和端口 // - 1234567890：TC生成的全局事务序列号

XID的生成过程：

1. TM通过GlobalTransactionScanner拦截@GlobalTransactional注解的方法

2. TM向TC发起begin请求，TC在内存中创建全局事务记录

3. TC根据配置的IP和端口，结合自增序列生成唯一XID

4. XID返回给TM，并存储在TC的后端存储中

1.4.2 XID的传递机制

在微服务调用链中，XID需要沿着调用路径向下传递，确保所有相关服务都能识别自己属于哪个全局事务。Seata通过事务上下文（Transaction Context）实现这一机制。

Seata支持多种上下文传递方式，以适应不同的微服务通信框架：

1. HTTP协议传递（用于Spring Cloud、Dubbo等）：

// 服务间调用时，XID通过HTTP Header传递 public class SeataHandlerInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String xid = request.getHeader("Seata-Xid"); if (StringUtils.isNotBlank(xid)) { // 将XID绑定到当前线程上下文 RootContext.bind(xid); } return true; } }

2. Dubbo过滤器传递：

// 通过Dubbo的RpcContext传递XID public class DubboTransactionPropagationFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) { String xid = RootContext.getXID(); if (StringUtils.isNotBlank(xid)) { // 将XID放入Dubbo附件中 RpcContext.getContext().setAttachment("Seata-Xid", xid); } return invoker.invoke(invocation); } }

3. 线程本地变量（ThreadLocal）传递：

// Seata核心的上下文持有类 public class RootContext { private static final ThreadLocal<String> CONTEXT_HOLDER = new ThreadLocal<>(); public static void bind(String xid) { CONTEXT_HOLDER.set(xid); } public static String getXID() { return CONTEXT_HOLDER.get(); } public static void unbind() { CONTEXT_HOLDER.remove(); } }

1.4.3 XID的生命周期管理

XID的生命周期与全局事务完全同步，其管理需要处理多种边界情况：

1. 事务传播场景：

   • 如果当前已存在XID，且传播行为为REQUIRED（默认），则加入现有事务

   • 如果传播行为为REQUIRES_NEW，则挂起当前事务，开启新事务

2. 异步调用场景：

   • 需要手动传递XID到子线程

   • 使用AsyncContext或自定义线程池包装器

3. 事务恢复场景：

   • TC重启后，从持久化存储中恢复未完成的事务

   • RM重新连接TC，获取未完成事务的XID列表

   • 继续完成未完成的事务分支

1.5 Seata的整体架构与核心流程

Seata采用分层架构设计，各层之间通过定义清晰的接口进行通信。这种设计提高了系统的可扩展性和可维护性。

1.5.1 整体架构层次

┌─────────────────────────────────────────────────────────────┐ │ 应用层 (Application Layer) │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ @GlobalTransactional GlobalTransaction │ │ │ │ 注解 API │ │ │ └───────────────────────────────────────────────────────┘ │ └─────────────────────────────────┬────────────────────────────┘ │ ┌─────────────────────────────────▼────────────────────────────┐ │ 事务管理层 (Transaction Management Layer) │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ TM (事务管理器) │ │ │ │ • 开启/提交/回滚全局事务 │ │ │ │ • 事务传播控制 │ │ │ └───────────────────────────────────────────────────────┘ │ └─────────────────────────────────┬────────────────────────────┘ │ ┌─────────────────────────────────▼────────────────────────────┐ │ 协调层 (Coordination Layer) │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ TC (事务协调器) │ │ │ │ • 全局事务状态管理 │ │ │ │ • 分支事务注册与协调 │ │ │ │ • 全局锁管理 │ │ │ └───────────────────────────────────────────────────────┘ │ └─────────────────────────────────┬────────────────────────────┘ │ ┌─────────────────────────────────▼────────────────────────────┐ │ 资源层 (Resource Layer) │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ RM (资源管理器) │ │ │ │ • 数据源代理 │ │ │ │ • SQL解析与执行 │ │ │ │ • 回滚日志生成 │ │ │ └───────────────────────────────────────────────────────┘ │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ 底层数据库 (MySQL, Oracle, etc.) │ │ │ └───────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘

1.5.2 核心工作流程

基于上述架构，Seata处理一个完整的分布式事务需要经历以下阶段：

阶段一：全局事务开启与分支注册

1. TM拦截@GlobalTransactional注解的方法

2. TM向TC申请开启全局事务，获取XID

3. TM将XID绑定到当前线程上下文

4. 业务SQL执行时，RM拦截SQL并向TC注册分支事务

5. RM执行业务SQL，生成undo_log（针对AT模式）

阶段二：全局事务提交/回滚

1. 业务方法执行完毕，TM根据执行结果决定提交或回滚

2. TM向TC发起全局提交或回滚请求

3. TC向所有相关RM下发相应指令

4. RM执行二阶段操作：提交时删除undo_log，回滚时执行补偿操作

5. TC更新全局事务状态为完成

1.5.3 高可用架构设计

在生产环境中，TC需要保证高可用性。Seata支持TC的集群部署：

# seata-server配置示例 seata: config: # 使用Nacos作为配置中心 type: nacos nacos: server-addr: 127.0.0.1:8848 registry: # 使用Nacos作为服务注册中心 type: nacos nacos: server-addr: 127.0.0.1:8848 cluster: default store: # 使用数据库存储事务日志，支持MySQL、Oracle等 mode: db db: datasource: druid db-type: mysql driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true user: seata password: seata

TC集群的关键设计要点：

1. 无状态设计：TC本身不存储状态，所有状态持久化到数据库

2. 负载均衡：TM/RM通过注册中心发现多个TC实例，实现负载均衡

3. 会话保持：一个全局事务的所有分支必须与同一个TC实例通信

4. 故障转移：TC实例故障时，注册中心会自动摘除故障节点

1.6 Seata的核心优势与适用场景

1.6.1 技术优势分析

1. 全链路解决方案：

   • 提供AT、TCC、Saga、XA四种模式，覆盖所有分布式事务场景

   • 与主流微服务框架（Spring Cloud、Dubbo）深度集成

   • 支持多注册中心（Nacos、Eureka、Consul等）和多配置中心

2. 性能优化显著：

   • 一阶段本地提交，避免长时间资源锁定

   • 二阶段异步化，减少对业务响应时间的影响

   • 全局锁优化，减少锁竞争和死锁概率

3. 高可用保障：

   • TC支持集群部署，避免单点故障

   • 完善的容错和恢复机制

   • 丰富监控指标和告警能力

1.6.2 适用场景分析

Seata特别适合以下场景：

1. 微服务架构下的数据一致性要求：

   • 电商订单、库存、账户的联动更新

   • 金融行业的转账、支付等核心交易

2. 遗留系统改造：

   • Saga模式适合长事务和遗留系统集成

   • 最小化对现有代码的改造

3. 混合事务模式需求：

   • 不同业务场景可能需要不同的事务模式

   • Seata允许在同一个应用中使用多种模式