一文搞懂Seata底层原理：核心架构、事务模式、运行机制

Seata（Simple Extensible Autonomous Transaction Architecture）是阿里开源的分布式事务框架，核心目标是简化分布式事务开发，支持AT/TCC/SAGA/XA四种事务模式，底层通过“协调者-参与者”架构实现跨服务的数据一致性。本文从核心架构、核心模式原理、运行流程、关键机制四部分，彻底讲透Seata的底层逻辑。

一、Seata核心架构：3大核心角色

Seata的底层架构围绕“中心化协调+分布式执行”设计，核心包含3个角色，职责边界清晰：

角色 中文名称 部署形态 核心职责
TC 事务协调器 独立服务（集群） 维护全局事务状态、协调全局事务提交/回滚、分配全局事务ID（XID）
TM 事务管理器 嵌入应用（微服务） 发起全局事务、注册全局事务到TC、触发全局提交/回滚
RM 资源管理器 嵌入应用（微服务） 管理分支事务（与TC交互注册/上报状态）、执行本地事务、响应TC的提交/回滚指令

核心交互流程（极简版）

sequenceDiagram participant TM (微服务A) participant TC (Seata Server) participant RM (微服务A) participant RM (微服务B) TM->>TC: 1. 发起全局事务，申请XID TC-->>TM: 返回XID TM->>RM(微服务A): 2. 执行本地分支事务（携带XID） RM(微服务A)->>TC: 注册分支事务（XID+分支ID） TC-->>RM(微服务A): 分支注册成功 RM(微服务A)-->>TM: 本地事务执行结果 TM->>RM(微服务B): 3. 调用微服务B（携带XID） RM(微服务B)->>TC: 注册分支事务 TC-->>RM(微服务B): 分支注册成功 RM(微服务B)-->>TM: 本地事务执行结果 alt 所有分支成功 TM->>TC: 4. 提交全局事务 TC->>RM(微服务A): 提交分支事务 TC->>RM(微服务B): 提交分支事务 else 任一分支失败 TM->>TC: 4. 回滚全局事务 TC->>RM(微服务A): 回滚分支事务 TC->>RM(微服务B): 回滚分支事务 end

二、Seata四大事务模式：底层原理与执行逻辑

Seata的核心差异体现在四种事务模式的底层实现，其中AT模式是默认且最常用的（无侵入），TCC/SAGA为业务侵入式，XA为强一致模式。

1. AT模式（Auto Transaction）：无侵入的最终一致性

AT模式是Seata的“王牌”，基于本地事务+自动补偿实现，对业务代码0侵入，底层分“执行阶段”和“提交/回滚阶段”：

（1）核心原理

  • 前提：数据库支持本地事务、支持行锁、RM侧通过JDBC代理拦截SQL。
  • 核心思想：“先执行，后补偿”——分支事务先执行并提交，异常时通过“前置镜像”反向补偿。

（2）两阶段执行流程

阶段1：分支事务执行（Try）
  1. SQL拦截：RM通过JDBC代理拦截业务SQL（如UPDATE t_stock SET num=num-1 WHERE id=1）。
  2. 前置镜像查询：执行SQL前，先查询目标数据的原始状态（如SELECT num FROM t_stock WHERE id=1），记录为“前置镜像”。
  3. 执行业务SQL：执行实际的更新操作。
  4. 后置镜像查询：执行SQL后，查询更新后的状态，记录为“后置镜像”。
  5. 分支注册：将XID、分支ID、镜像数据上报TC，然后提交本地事务（重点：AT模式阶段1就提交本地事务，无锁阻塞）。
阶段2：全局提交/回滚
  • 全局提交：TC通知所有RM提交分支 → RM直接删除镜像数据（无实际业务操作，轻量）。
  • 全局回滚：TC通知所有RM回滚分支 → RM根据“前置镜像”生成补偿SQL（如UPDATE t_stock SET num=10 WHERE id=1），执行补偿并删除镜像数据。

（3）关键保障机制

  • 脏写防护：执行SQL时通过FOR UPDATE加行锁，防止并发修改导致数据不一致。
  • 幂等/空回滚/悬挂：内置状态管理，自动处理这三类异常（无需业务代码干预）。

（4）底层存储

  • TC侧：存储全局事务状态、分支事务信息（支持MySQL/Redis等）。
  • RM侧：临时存储镜像数据（表名：undo_log），事务完成后删除。

2. TCC模式（Try-Confirm-Cancel）：业务侵入式高性能

Seata的TCC模式是对标准TCC的封装，底层核心是“业务接口化+状态管控”：

（1）底层执行逻辑

  1. 接口定义：业务需实现3个接口（prepare/commit/rollback），并通过注解标记（@TccAction）。
  2. 阶段1（Try）：TM发起全局事务，调用RM的prepare方法（资源预占），RM将分支状态上报TC。
  3. 阶段2（Confirm/Rollback）：TC根据全局状态，调用RM的commit（确认预占资源）或rollback（释放预占资源）。

（2）Seata的增强

  • 自动处理空回滚/悬挂/幂等：通过TC维护的分支状态，自动校验并拦截异常请求。
  • 无锁设计：阶段1不提交最终业务，仅预占资源，无长期锁阻塞。

3. SAGA模式：长事务适配

Seata的SAGA模式针对长流程分布式事务设计，底层基于“状态机+补偿链”实现：

（1）核心原理

  1. 事务定义：通过JSON/YAML定义SAGA状态机（如下单→扣库存→减余额的正向流程，减余额失败→补偿减余额→补偿扣库存→补偿下单的反向流程）。
  2. 状态驱动：TC根据状态机定义，驱动各RM执行正向/补偿操作。
  3. 补偿执行：支持“串行/并行”补偿，支持重试（失败自动重试，可配置重试策略）。

（2）底层特点

  • 无锁：所有分支事务均为本地提交，无资源锁定。
  • 柔性：允许部分节点失败后重试，适配长流程（如订单履约、旅行预订）。

4. XA模式：强一致性（兼容标准XA协议）

Seata的XA模式是对数据库XA协议的封装，底层完全遵循2PC流程：

（1）执行逻辑

  1. 阶段1（Prepare）：RM执行本地事务，但不提交（XA prepare），上报状态到TC。
  2. 阶段2（Commit/Rollback）：TC通知所有RM提交（XA commit）或回滚（XA rollback）。

（2）底层特点

  • 强一致：完全遵循ACID，适合金融核心场景。
  • 性能差：阶段1持有数据库锁，同步阻塞，仅适合低并发场景。

三、Seata底层关键机制：稳定性保障

1. 通信机制

  • 底层基于Netty实现TC-RM/TM的长连接通信，支持心跳检测、断线重连。
  • 协议：自定义TCP协议（Seata Protocol），轻量且高效。

2. 高可用机制

  • TC集群化：通过注册中心（Nacos/Eureka）实现TC集群部署，TM/RM自动发现可用TC节点。
  • 数据持久化：TC的事务状态持久化到数据库/Redis，宕机重启后可恢复。
  • 重试机制：RM与TC通信失败时，自动重试（可配置重试次数/间隔）。

3. 序列化与存储

  • 序列化：默认使用Hessian，支持JSON/Protobuf（高性能场景推荐Protobuf）。
  • 存储选型：
    • 测试/轻量场景：TC使用File存储（无需数据库）。
    • 生产场景：TC使用MySQL/PostgreSQL（事务状态持久化），RM的undo_log存储在业务库。

四、Seata底层与传统分布式事务的差异

特性 Seata AT模式 传统2PC（XA） 手写TCC
侵入性 0侵入（业务无感知） 低侵入（数据库层） 高侵入（需写3个接口）
性能 高（阶段1提交，无锁） 低（阶段1持锁，阻塞） 中高（无锁，业务优化）
一致性 最终一致 强一致 最终一致
异常处理 自动处理（幂等/空回滚/悬挂） 手动处理 手动处理
适用场景 微服务通用场景 金融核心强一致场景 高并发短事务

五、总结

  1. 核心架构：Seata通过TC（协调）、TM（发起）、RM（执行）三层架构实现分布式事务，所有操作围绕XID（全局事务ID） 关联。
  2. 核心模式：AT模式是Seata的核心（0侵入、最终一致），底层通过“镜像数据+自动补偿”实现；TCC/SAGA适配高并发/长事务，XA适配强一致场景。
  3. 关键保障：Seata内置幂等、空回滚、悬挂等异常处理机制，底层通过Netty通信、集群化部署保证高可用，相比传统方案更轻量、更适配微服务。
posted @ 2026-03-11 22:15  七星6609  阅读(1)  评论(0)    收藏  举报