《Seata从入门到实战》第一章：Seata核心概念与架构
本期内容为自己总结归档，欢迎评论区指正~
第一章：Seata核心概念与架构概览
第二章：AT 模式详解
第三章：TCC模式详解
第四章：Saga模式详解
第五章：XA模式详解
第六章：seata从部署到集成实战&避坑指南
第七章：seata总结
点赞关注哦~
第一章：Seata核心概念与架构概览
1.1 分布式事务的核心挑战与Seata的解决方案
在微服务架构成为主流的今天，一个业务操作经常需要跨越多个服务边界，每个服务都可能操作独立的数据库。传统的单体应用依靠数据库的ACID事务保证数据一致性，但这种机制在服务被拆分后完全失效。这引出了分布式系统领域的经典难题——如何在分布式环境下保证跨服务、跨数据库的数据操作具有一致性。
分布式事务面临的核心挑战主要体现在CAP定理的约束下：
-
原子性（Atomicity）难以保障：在分布式环境中，一个全局事务由多个本地事务组成。由于网络分区、节点故障等不可控因素，无法保证所有参与节点在同一时刻达成一致提交或回滚的决定。
-
隔离性（Isolation）实现复杂：传统数据库通过锁机制实现隔离级别，但在分布式场景下，跨服务的读写操作可能产生难以察觉的脏读、不可重复读和幻读问题，且分布式锁的引入又会严重影响系统性能。
-
协调成本高昂：需要一个可靠的协调者来管理所有参与者的状态，协调者本身的可用性、性能瓶颈都会成为系统的单点故障风险。
业界常见的分布式事务解决方案如两阶段提交（2PC）、三阶段提交（3PC）、消息队列最终一致性等，各自存在明显的局限性。正是在这样的背景下，阿里巴巴开源了Seata（Simple Extensible Autonomous Transaction Architecture），旨在提供一站式、高性能、易集成的分布式事务解决方案。
Seata的核心设计哲学是：像使用本地事务一样使用分布式事务。它通过对业务极低的侵入性，将复杂的分布式事务问题封装在框架内部，让开发者聚焦业务逻辑本身。
1.2 Seata的演进历程与核心设计思想
Seata的发展历程体现了对分布式事务问题理解的不断深化：
-
第一阶段：AT模式主导期（2019年初）
-
基于两阶段提交思想的增强版，通过全局锁和回滚日志实现自动补偿
-
优势：对业务代码零侵入，接入成本极低
-
局限：对数据库操作有约束，全局锁可能成为性能瓶颈
-
-
第二阶段：多模式并存期（2019-2020）
-
引入TCC、Saga、XA模式，形成完整的分布式事务解决方案矩阵
-
针对不同业务场景提供差异化选择
-
架构上进行解耦，TC（事务协调器）可独立部署
-
-
第三阶段：高性能与云原生（2021至今）
-
支持高可用集群部署
-
优化全局锁竞争，减少性能损耗
-
增强与云原生组件的集成能力
-
Seata的核心设计思想可以概括为三个关键词：
-
解耦：将事务协调逻辑从业务服务中彻底分离，通过独立的TC组件集中管理事务状态。
-
分层：架构上清晰划分为协调层（TC）和参与层（TM/RM），各层职责单一。
-
可插拔：支持多种事务模式，可根据业务特点灵活选择和组合。
这种设计使得Seata既能保持框架的简洁性，又能应对复杂的业务场景需求。
1.3 Seata的核心组件与职责划分
Seata的架构采用经典的协调者-参与者模式，但进行了重要改进。整个系统由三个核心组件构成，它们各司其职，协同完成分布式事务管理。
1.3.1 TC（Transaction Coordinator）- 事务协调器
TC是Seata架构的大脑和中枢，负责协调分布式事务的最终状态。它的核心职责包括：
-
全局事务管理：
-
维护全局事务的生命周期状态（BEGIN, COMMITTING, COMMITTED, ROLLBACKING, ROLLBACKED）
-
生成全局唯一的XID（全局事务ID）并传播到整个调用链
-
接收TM的全局事务提交/回滚指令，驱动所有分支事务完成两阶段提交或回滚
-
-
分支事务注册与状态追踪：
-
接收RM的分支事务注册请求，建立全局事务与分支事务的映射关系
-
监控所有分支事务的执行状态，为全局决策提供依据
-
-
全局锁管理（针对AT模式）：
-
维护全局行锁，防止多个分布式事务同时修改同一数据
-
处理锁的获取、释放和超时机制
-
解决分布式环境下的写-写冲突问题
-
TC在设计上采用无状态架构，所有事务状态都持久化存储在数据库中（如MySQL）。这使得TC可以轻松实现水平扩展和高可用部署，通过集群化避免单点故障。
1.3.2 TM（Transaction Manager）- 事务管理器
TM是分布式事务的发起者和边界定义者，通常嵌入在业务服务中。它的主要职责包括：
-
事务边界定义：
-
通过
@GlobalTransactional注解或API调用声明一个全局事务的开始 -
确定哪些操作需要纳入同一个分布式事务的管辖范围
-
-
全局事务控制：
-
向TC发起全局事务开始请求，获取XID
-
根据业务执行结果，决定向TC发起全局提交或回滚请求
-
处理超时和异常情况，确保事务的最终一致性
-
-
事务上下文管理：
-
将XID注入到当前线程上下文
-
确保XID在服务调用链中正确传递
-
在事务结束时清理上下文资源
-
TM的设计体现了Seata对业务低侵入的理念。开发者只需在方法上添加一个注解，框架就会自动处理复杂的分布式事务逻辑。
1.3.3 RM（Resource Manager）- 资源管理器
RM是分布式事务的最终执行者，负责与底层资源（主要是数据库）交互。每个参与分布式事务的微服务都会有一个RM实例。RM的核心职责包括：
-
分支事务管理：
-
向TC注册分支事务，建立与全局事务的关联
-
执行业务SQL，生成对应的回滚日志（针对AT模式）
-
向TC报告分支事务的执行状态
-
-
本地资源协调：
-
管理数据库连接，将XID与数据库连接绑定
-
在AT模式下，拦截SQL执行，生成前后镜像数据
-
在TCC模式下，调用Try、Confirm、Cancel方法
-
-
事务指令响应：
-
接收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的生成过程：
-
TM通过
GlobalTransactionScanner拦截@GlobalTransactional注解的方法 -
TM向TC发起
begin请求，TC在内存中创建全局事务记录 -
TC根据配置的IP和端口，结合自增序列生成唯一XID
-
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 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的生命周期与全局事务完全同步，其管理需要处理多种边界情况：
-
事务传播场景：
-
如果当前已存在XID，且传播行为为REQUIRED（默认），则加入现有事务
-
如果传播行为为REQUIRES_NEW，则挂起当前事务，开启新事务
-
-
异步调用场景：
-
需要手动传递XID到子线程
-
使用
AsyncContext或自定义线程池包装器
-
-
事务恢复场景：
-
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处理一个完整的分布式事务需要经历以下阶段：
阶段一：全局事务开启与分支注册
-
TM拦截
@GlobalTransactional注解的方法 -
TM向TC申请开启全局事务，获取XID
-
TM将XID绑定到当前线程上下文
-
业务SQL执行时，RM拦截SQL并向TC注册分支事务
-
RM执行业务SQL，生成undo_log（针对AT模式）
阶段二：全局事务提交/回滚
-
业务方法执行完毕，TM根据执行结果决定提交或回滚
-
TM向TC发起全局提交或回滚请求
-
TC向所有相关RM下发相应指令
-
RM执行二阶段操作：提交时删除undo_log，回滚时执行补偿操作
-
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: seataTC集群的关键设计要点：
-
无状态设计：TC本身不存储状态，所有状态持久化到数据库
-
负载均衡：TM/RM通过注册中心发现多个TC实例，实现负载均衡
-
会话保持：一个全局事务的所有分支必须与同一个TC实例通信
-
故障转移：TC实例故障时，注册中心会自动摘除故障节点
1.6 Seata的核心优势与适用场景
1.6.1 技术优势分析
-
全链路解决方案：
-
提供AT、TCC、Saga、XA四种模式，覆盖所有分布式事务场景
-
与主流微服务框架（Spring Cloud、Dubbo）深度集成
-
支持多注册中心（Nacos、Eureka、Consul等）和多配置中心
-
-
性能优化显著：
-
一阶段本地提交，避免长时间资源锁定
-
二阶段异步化，减少对业务响应时间的影响
-
全局锁优化，减少锁竞争和死锁概率
-
-
高可用保障：
-
TC支持集群部署，避免单点故障
-
完善的容错和恢复机制
-
丰富监控指标和告警能力
-
1.6.2 适用场景分析
Seata特别适合以下场景：
-
微服务架构下的数据一致性要求：
-
电商订单、库存、账户的联动更新
-
金融行业的转账、支付等核心交易
-
-
遗留系统改造：
-
Saga模式适合长事务和遗留系统集成
-
最小化对现有代码的改造
-
-
混合事务模式需求：
-
不同业务场景可能需要不同的事务模式
-
Seata允许在同一个应用中使用多种模式
-
