什么是seata¶

https://seata.apache.org/docs/next/overview/what-is-seata

类别	词条	详细说明
分布式事务模型	Seata	Apache Seata 是一个开源的分布式事务解决方案，提供高性能、易用的分布式事务服务，支持AT、TCC、Saga和XA四种事务模型。
	AT模式（Automatic Transaction）	基于支持本地ACID事务的关系型数据库，通过两阶段提交协议实现分布式事务，自动生成回滚日志并异步清理。
	TCC模式（Try-Confirm-Cancel）	不依赖底层数据资源的事务支持，通过自定义的Prepare、Commit、Rollback逻辑实现分布式事务管理。
	Saga模式	长事务解决方案，通过正向服务（提交本地事务）和补偿服务（失败时回滚）实现业务一致性，适用于跨系统或遗留系统的长流程场景。
事务机制	两阶段提交协议（2PC）	AT模式的核心机制，分为两个阶段： 1. 阶段一：提交业务数据及回滚日志，释放本地锁和连接资源； 2. 阶段二：异步提交或基于回滚日志补偿。
	全局锁（Global Lock）	在AT模式中，本地事务提交前必须获取全局锁，确保数据一致性。若获取失败，事务会重试或超时回滚。
隔离机制	写隔离（Write Isolation）	通过全局锁避免脏写问题。在事务提交前获取全局锁，其他事务需等待锁释放后才能继续操作。
	读隔离（Read Isolation）	默认全局事务隔离级别为“读未提交”，通过`SELECT FOR UPDATE`语句实现“读已提交”级别，查询时会申请全局锁并阻塞直到锁释放。
数据操作	Before Image	更新前的数据镜像，用于生成回滚日志和补偿操作。
	After Image	更新后的数据镜像，与Before Image共同构成回滚日志，用于数据校验和补偿。
	UNDO_LOG表	存储事务回滚信息的表，结构包含分支事务ID（`branch_id`）、全局事务ID（`xid`）、回滚数据（`rollback_info`）等字段，用于事务失败时的数据恢复。
核心流程	阶段一（Phase 1）	解析SQL、生成Before/After Image、插入UNDO_LOG、申请全局锁并提交本地事务。
	阶段二（Phase 2）	分为两种情况： 1. 回滚：校验数据一致性，生成反向SQL并提交本地事务； 2. 提交：异步删除UNDO_LOG。
Saga模式特性	正向服务	Saga参与者提交本地事务，若后续参与者失败，触发已提交参与者的补偿操作。
	补偿服务	自定义的回滚逻辑，用于回滚正向服务的操作。
	优点	无锁、高性能、支持异步执行和高吞吐量，适用于长流程和跨系统场景。
	缺点	缺乏隔离性，可能出现脏读或中间状态暴露。
技术依赖	关系型数据库	AT模式要求数据库支持本地ACID事务（如MySQL）。
	SELECT FOR UPDATE	用于实现全局事务的“读已提交”隔离级别，执行时会申请全局锁并阻塞其他事务。
其他概念	分支事务（Branch Transaction）	全局事务的组成部分，每个分支事务需满足两阶段提交模型（如AT或TCC模式）。
	本地事务	单个数据库实例上的ACID事务，AT模式通过本地事务提交业务数据和UNDO_LOG。

总结¶

Apache Seata 是一个支持多模型的分布式事务框架，其核心机制包括 AT模式（基于两阶段提交和全局锁实现数据一致性）、TCC模式 **（通过自定义Prepare/Commit/Rollback逻辑管理事务）、**Saga模式（适用于长流程的无锁异步事务）。关键技术点包括：

隔离机制：通过全局锁和SELECT FOR UPDATE实现写隔离和读隔离；
数据回滚：利用Before/After Image生成UNDO_LOG，支持事务失败时的自动补偿；
适用场景：AT模式适合强一致性场景，TCC适用于自定义事务逻辑，Saga适用于跨系统长流程。
Seata通过灵活的事务模型和底层优化，解决了分布式系统中的数据一致性问题，同时平衡了性能与复杂度。

示例¶

https://seata.apache.org/docs/user/quickstart | 类别 | 词条 | 详细说明 ** | |---------------------------|-----------------------------------|-----------------------------------------------------------------------------------------------| | **微服务组件 | StorageService | 库存服务，负责减少指定商品的库存数量。 | | | OrderService | 订单服务，根据用户请求创建订单。 | | | AccountService | 账户服务，从用户账户中扣减余额。 | | 接口方法 | deduct() | 属于StorageService接口，用于减少商品库存数量。 | | | create() | 属于OrderService接口，创建订单并调用账户服务扣款。 | | | debit() | 属于AccountService接口，从用户账户中扣减指定金额。 | | Seata组件 | @GlobalTransactional | 注解，用于标记需要分布式事务管理的方法（如purchase()方法）。 | | | AT模式（Auto Transaction Mode） | Seata的事务模式，通过全局锁和两阶段提交（2PC）实现分布式事务。 | | | UNDO_LOG表 | 用于存储事务回滚日志，支持AT模式下的事务恢复。 | | 数据库相关 | storage_tbl | 库存表，存储商品库存信息，字段包括commodity_code（商品编码）和count （数量）。 | | | order_tbl | 订单表，存储订单信息，字段包括user_id、commodity_code、count和money。 | | | account_tbl | 账户表，存储用户账户余额，字段包括user_id和money。 | | | InnoDB引擎 | MySQL数据库引擎，支持事务和行级锁，是Seata AT模式的基础要求。 | | 事务模式与配置 | 两阶段提交（2PC） | 分布式事务协议，分为准备阶段和提交/回滚阶段，Seata通过AT模式自动实现。 | | | storeMode | Seata服务端配置参数，支持日志存储模式（如file或db）。 | | 示例代码元素 | BusinessServiceImpl | 主业务逻辑类，调用库存服务和订单服务完成用户购买操作。 | | | OrderServiceImpl | 订单服务实现类，计算订单金额并调用账户服务扣款，最终插入订单记录。 | | 配置参数 | seata-server.sh/seata-server.bat | Seata服务端启动脚本，支持参数如-h（绑定IP）、-p （端口）、-m（日志存储模式）。 | | 核心流程 | 全局事务管理 | 通过Seata协调微服务调用，保证所有操作要么全部成功，要么全部回滚。 | | 数据库表结构 | UNDO_LOG表字段 | 包含xid（全局事务ID）、branch_id（分支事务ID）、rollback_info （回滚数据）等字段。 |

总结段落¶

本文档介绍了Apache Seata在微服务场景下的分布式事务解决方案。通过一个用户购买商品的业务案例，展示了库存服务（ StorageService）、订单服务（OrderService）和账户服务（AccountService）的协作流程。Seata通过@GlobalTransactional 注解实现全局事务管理，核心机制是**AT模式**，依赖UNDO_LOG表记录事务回滚日志，并结合两阶段提交（2PC）保障数据一致性。
配置方面，需为每个服务创建独立的数据源（如storage_tbl、order_tbl、account_tbl），并确保数据库使用InnoDB引擎。Seata服务端通过命令行参数（如 -m指定日志存储模式）启动，支持高可用和灵活部署。文档还提供了完整的SQL表结构定义和示例代码，帮助开发者快速实现基于Dubbo和Seata的分布式事务集成。

Seata AT Mode¶

https://seata.apache.org/docs/user/mode/at

类别	词条	详细说明
事务模式	Seata AT Mode	由Seata提出的非侵入式分布式事务解决方案，通过内置数据源代理自动管理事务操作（如插入回滚日志、全局锁检查），业务代码无需显式处理事务细节。
事务机制	两阶段提交协议（2PC）	Seata对传统两阶段提交的改进：第一阶段提交业务数据和回滚日志，释放本地锁；第二阶段异步提交或通过回滚日志补偿，减少资源占用。
核心组件	数据源代理（DataSourceProxy）	Seata提供的代理类，用于包装业务数据源，自动记录undo_log（回滚日志）和全局锁检查，是AT模式实现非侵入式事务的基础。
事务操作	@GlobalTransactional	全局事务注解，标记方法开启分布式事务，类似Spring的@Transactional，但作用于跨数据源的场景，确保多个数据源操作的一致性。
日志与锁	undo_log	回滚日志表，记录事务操作的前后镜像数据，用于第二阶段失败时进行数据回滚。
全局锁	全局锁	Seata在AT模式中用于防止分布式事务间的数据脏读和写冲突，通过代理层在操作数据时自动检查并获取全局锁。
数据源实例	jdbcTemplateA/jdbcTemplateB	示例中使用的不同数据源实例，需分别通过DataSourceProxy代理，以实现跨数据源的事务协调。
事务阶段	第一阶段（Phase 1）	本地事务阶段：提交业务数据变更和undo_log到本地数据库，释放本地锁和连接资源。
事务阶段	第二阶段（Phase 2）	全局协调阶段：异步提交所有分支事务（快速完成）或根据undo_log回滚数据（补偿机制）。
隔离性	事务隔离	AT模式通过全局锁实现读已提交（RC）隔离级别，避免脏读；本地事务隔离级别依赖底层数据库（如MySQL的默认隔离级别）。
使用场景	跨数据源事务	适用于微服务架构中，不同服务操作独立数据库的场景（如示例中的库存表`stock_tbl`和账户表`account_tbl`分属不同数据源）。

总结¶

Seata AT模式是一种非侵入式的分布式事务解决方案，通过代理数据源（DataSourceProxy）自动管理事务操作，简化了跨数据源事务的开发。其核心机制基于改进的两阶段提交协议（2PC），第一阶段在本地事务中提交业务数据和回滚日志（undo_log），第二阶段异步提交或通过日志回滚。关键组件包括全局事务注解（@GlobalTransactional）、全局锁（防止脏读）和undo_log（数据补偿）。该模式适用于微服务中跨数据库的场景（如库存与账户分离），通过RC隔离级别保障一致性，且与Spring框架无缝集成，显著降低了分布式事务的改造成本。

Seata TCC 模式¶

https://seata.apache.org/docs/dev/mode/tcc-mode

类别	词条	详细说明
事务模式	TCC模式	一种分布式事务模式，通过自定义的`prepare`、`commit`、`rollback`逻辑实现两阶段提交，不依赖底层数据资源的事务支持。
	AT模式	基于支持本地ACID事务的关系型数据库，通过自动生成回滚日志和异步清理实现两阶段提交。
	Saga模式	通过长事务拆分和补偿机制处理分布式事务的模式（未在文中详细展开）。
	XA模式	基于XA协议实现分布式事务协调的模式（未在文中详细展开）。
核心概念	全局事务	由多个分支事务组成的分布式事务，整体遵循两阶段提交模型。
	分支事务	全局事务的组成部分，每个分支需满足两阶段提交的要求（如`prepare`、`commit`/`rollback`）。
	两阶段提交模型	分布式事务的核心模型，分为`prepare`阶段（一阶段）和`commit`/`rollback`阶段（二阶段）。
分支事务行为	Prepare行为	一阶段执行自定义的业务逻辑准备操作（如资源预留），为后续提交或回滚提供基础。
	Commit行为	二阶段执行提交逻辑，确认资源操作（如正式扣款）。
	Rollback行为	二阶段执行回滚逻辑，撤销一阶段的操作（如释放预留资源）。
设计模型	领域模型	Seata中的事务管理抽象模型，用于描述全局事务与分支事务的关系。
	配置隔离	支持多环境或多版本配置隔离的机制（未展开细节）。
技术对比	AT vs. TCC	AT依赖数据库事务和自动回滚日志，TCC需完全自定义两阶段逻辑且不依赖底层事务。
核心组件	回滚日志（AT模式）	AT模式下用于记录数据变更前状态的日志，用于自动生成补偿操作。
	异步清理（AT模式）	AT模式下二阶段提交后自动异步删除回滚日志，提升性能。
流程设计	补偿操作	在事务失败时通过回滚日志自动执行反向操作，保证数据一致性（AT模式）。
补偿机制	自定义回滚逻辑（TCC）	TCC模式下需开发者显式实现回滚逻辑（如资源释放）。
事务管理	全局事务协调	Seata通过事务协调器（TC）管理全局事务状态和分支事务的生命周期。
日志管理	回滚日志生成（AT模式）	AT模式下在本地事务提交时同步生成回滚日志，用于可能的补偿操作。

总结¶

本文详细阐述了 Seata TCC模式 的核心机制及其与其他事务模式（如AT模式）的对比。TCC模式基于两阶段提交模型，要求开发者自定义分支事务的 prepare、commit和rollback逻辑，不依赖底层数据库事务支持。与之相比，AT模式 通过自动生成回滚日志和异步清理实现自动化补偿，适用于支持ACID的关系型数据库。全局事务由多个分支事务组成，需严格遵循两阶段行为。TCC的灵活性体现在需显式处理资源操作和回滚逻辑，而AT模式通过数据库特性简化了开发。此外，文中提及了Seata的领域模型、配置隔离、异步清理等设计细节，强调其对分布式事务全生命周期的管理能力，最终通过不同模式的适用场景为开发者提供多样化选择。

SEATA Saga 模式¶

类别	词条	详细说明
理论背景	Sagas (1987)	Hector & Kenneth提出的长事务处理理论，Saga模式的原始理论基础，通过本地事务提交和补偿机制实现最终一致性。
核心概念	Saga模式	Seata提供的长事务解决方案，参与者提交本地事务，失败时通过补偿回滚已成功的操作。
核心概念	状态机引擎	Saga模式的实现核心，通过JSON定义状态图驱动服务调用流程，支持正向服务执行和反向补偿。
核心概念	补偿节点	状态图中每个服务节点配置的补偿逻辑，用于在异常时回滚已提交的本地事务。
核心概念	正向服务	业务流程中正常执行的服务阶段。
核心概念	补偿服务	在异常时执行的反向操作，用于回滚正向服务的影响。
设计原理	事件驱动模型	状态机引擎的底层机制，通过事件队列（EventQueue）驱动状态节点的执行和路由。
设计原理	状态图	以图形化方式定义服务调用流程的JSON文件，包含节点执行顺序、补偿关系及参数映射。
设计原理	本地数据库记录事件	状态机引擎执行过程中，将事务启动、状态实例执行、分支注册等事件持久化到本地数据库，用于故障恢复。
组件与机制	分支事务	分布式事务中每个参与者的本地事务单元，由Seata Server统一协调提交或回滚。
组件与机制	XID（事务ID）	全局唯一的事务标识符，由Seata Server生成，用于关联分布式事务的所有分支。
组件与机制	分支ID	单个分支事务的唯一标识符，由Seata Server分配。
组件与机制	事件队列（EventQueue）	存储状态节点执行过程中产生的路由消息，供消费者按顺序处理。
功能与特性	服务编排	支持业务流程的单选、并发、子流程嵌套等复杂逻辑编排。
功能与特性	参数转换与映射	在状态节点间传递和转换参数，支持灵活的数据处理逻辑。
功能与特性	异常捕获与补偿决策	允许用户自定义异常处理逻辑（如是否触发补偿），增强流程可控性。
技术术语	事务提交/回滚	分布式事务的最终操作，由Seata Server根据所有分支的执行状态决定提交或回滚。
技术术语	服务调用	状态节点中执行的具体业务操作，如调用微服务或数据库事务。
架构层次	Eventing层	状态机引擎的底层事件驱动架构，负责事件的生产和消费，不关注具体业务逻辑。
架构层次	ProcessController层	基于Eventing层的流程控制层，实现状态节点的路由和逻辑执行，但不处理状态行为。
架构层次	StateMachineEngine层	顶层状态机引擎，实现状态节点的具体行为（如服务调用、补偿触发）和状态图解析，提供API和状态语言仓库。

总结¶

Apache Seata的Saga模式通过**状态机引擎**实现长事务管理，其核心是基于**事件驱动模型**的服务编排机制。状态机引擎通过**状态图 定义业务流程，每个节点执行**正向服务**并支持配置**补偿节点，异常时反向触发补偿逻辑。引擎在运行中依赖**本地数据库** 记录事务事件（如XID、分支ID），并与Seata Server协作完成分支事务的注册和状态上报。其架构分为三层：底层**Eventing层**处理事件驱动，中间层 ProcessController**管理流程路由，顶层**StateMachineEngine**实现状态行为。通过支持**参数转换、异常捕获**及**服务编排 等特性，Saga模式能够灵活处理复杂业务场景，最终通过补偿机制保障分布式事务的一致性。

Seata XA 模式¶

https://seata.apache.org/docs/user/mode/xa

类别	词条	详细说明
事务模式	Seata XA Mode	Seata框架中基于XA协议实现分布式事务的模式，利用数据库或消息服务等支持XA协议的资源，确保分支事务的提交或回滚符合全局事务一致性要求。
前提条件	XA事务数据库	数据库需支持XA协议的事务机制，如MySQL、Oracle等。
	JDBC访问的Java应用	通过JDBC连接数据库的Java应用程序，需适配XA模式的数据源代理。
机制阶段	执行阶段（Execute）	包含XA start/XA end/XA prepare等操作，结合SQL执行和分支注册，保证事务的持久性和可回滚性。
	完成阶段（Finish）	根据全局事务状态执行XA commit或XA rollback，完成分支事务的最终提交或回滚。
技术组件	XA协议	一种分布式事务处理标准协议，通过两阶段提交（2PC）确保跨资源的事务一致性。
	XAConnection	XA模式中用于管理XA事务的数据库连接，需通过XADataSource或普通DataSource代理生成。
	DataSourceProxy	Seata中对数据源的代理机制，分为两种实现：基于普通DataSource生成XAConnection（透明编程）或直接代理XADataSource（需显式配置）。
操作步骤	XA start/XA end/XA prepare	XA事务的核心操作，用于启动、结束和预提交事务分支。
	分支注册（Register Branch）	在XA start前将分支事务注册到Seata事务协调器（TC），关联全局事务XID和BranchId，以便后续驱动提交或回滚。
	XA commit/XA rollback	根据全局事务状态，在完成阶段提交或回滚XA分支事务。
数据源配置	普通DataSource代理	开发者无需显式配置XADataSource，Seata自动将普通JDBC连接包装为XAConnection，但可能因数据库驱动差异导致兼容性问题（如Oracle）。
	XADataSource代理	显式配置XADataSource，由Seata直接代理，避免兼容性问题，但增加开发者对XA协议的学习负担。
优化方向	分支注册延迟优化	未来可能将分支注册推迟到本地事务提交前，减少无效分支注册（需改进BranchId生成机制）。
兼容性问题	数据库驱动差异	不同数据库厂商或版本的驱动实现可能影响XAConnection生成的正确性（如Druid与Oracle的兼容性问题）。

总结段落¶

Seata XA模式是Seata框架中基于XA协议的分布式事务解决方案，其核心机制分为**执行阶段**和**完成阶段**。在执行阶段，通过 XA start/XA end/XA prepare操作结合SQL执行和分支注册，确保事务的持久性和可回滚性；完成阶段则根据全局事务状态执行 XA commit或XA rollback。关键组件包括**XA协议**、XAConnection**和**DataSourceProxy，后者支持两种配置方式：代理普通 DataSource（透明但可能存在驱动兼容性问题）或直接代理XADataSource （需显式配置但更可靠）。分支注册需在XA操作前完成，未来可能通过延迟注册优化性能。开发者需注意数据库驱动的兼容性（如Oracle），并在编程模型上与AT模式保持一致，仅需切换数据源代理即可实现模式切换。整体上，XA模式通过标准XA协议保证强一致性，适用于对事务一致性要求严格的场景。

Seata Domain Model Seata 域模型¶

https://seata.apache.org/docs/dev/domain/overviewDomainModel

类别	词条	详细说明
核心定义	Seata	分布式事务架构（Simple Extensible Autonomous Transaction Architecture），用于解决分布式架构下的数据一致性问题，支持XA、AT、TCC、SAGA等多种事务模式，提供无侵入、高性能、高可用的事务管理能力。
	分布式事务	跨多个服务或数据库的事务操作，需保证数据一致性，Seata通过两阶段提交（2PC）或基于BASE理论的最终一致性实现。
事务模式	XA模式	基于数据库原生XA协议的事务模式，由TC协调全局事务的提交或回滚，无业务侵入。
	AT模式	自动补偿型事务模式，通过解析SQL生成反向回滚日志（undo log），在提交阶段删除日志，回滚时执行反向操作。
	TCC模式	基于业务逻辑的补偿型事务模式，通过Try-Confirm-Cancel三阶段实现事务控制，需开发者自定义补偿逻辑，与具体服务框架解耦。
	SAGA模式	长事务解决方案，支持最终一致性，通过状态机编排事务分支，可自定义事务补偿逻辑。
核心组件	事务管理器（TM）	负责全局事务的创建、提交或回滚决策，通常位于业务调用链的上游（如微服务调用方）。
	资源管理器（RM）	管理分支事务的资源（如数据库连接），负责分支事务的注册、状态上报和本地事务执行，通常位于服务提供方。
	事务协调器（TC）	协调全局事务的两阶段提交行为（除SAGA外），驱动事务的提交、回滚或超时回滚，独立部署，支持高可用。
事务生命周期	Begin（事务创建）	TM发起全局事务，生成全局唯一XID，并注册到TC。
	Registry（分支事务注册）	RM向TC注册分支事务，关联全局XID，上报分支事务状态。
	Commit/Rollback（事务提交/回滚）	TM向TC发送提交或回滚指令，TC协调所有分支事务执行两阶段操作（如AT的undo log删除、TCC的Confirm/Cancel）。
事务处理场景	提交（Commit）	全局事务成功时，TC驱动所有分支事务执行第二阶段提交操作（如XA Commit、TCC Confirm）。
	回滚（Rollback）	全局事务失败或主动回滚时，TC驱动分支事务执行反向操作（如AT执行undo log、TCC Cancel）。
	超时回滚（Timeout Rollback）	当全局事务超时未完成时，TC主动触发回滚，行为与普通回滚一致。
高可用设计	事务组（tx-service-group）	逻辑资源分组，客户端根据业务需求定义事务组名称，TC集群通过组名提供服务，实现资源隔离和负载均衡。
	服务发现	TC通过注册中心（如Nacos、Eureka、ZooKeeper）暴露服务地址，客户端通过事务组名动态发现可用TC节点。
特性与优势	无侵入性	XA和AT模式无需修改业务代码即可实现分布式事务。
	协议无关性	不依赖底层RPC协议（如HTTP、Dubbo、gRPC均可支持）。
	存储无关性	支持多种存储介质（如MySQL、Oracle、Redis等），事务状态和日志可灵活存储。
	最终一致性	基于BASE理论，适用于对强一致性要求较低的场景（如SAGA模式）。
	高性能	AT模式通过反向日志实现高效回滚，减少锁竞争；TCC模式通过异步Confirm/Cancel提升吞吐量。

总结¶

Apache Seata是一个专注于解决分布式事务一致性的框架，其核心设计围绕**事务管理器（TM）、**资源管理器（RM）**和 事务协调器（TC）**三个组件展开，支持XA、AT、TCC、SAGA四种事务模式，覆盖从强一致到最终一致的不同业务场景。

**XA和AT模式**通过无侵入方式实现事务管理，前者依赖数据库原生协议，后者利用SQL解析生成反向日志；
TCC和SAGA模式**则要求业务层定义补偿逻辑，适用于复杂长事务场景。
Seata通过**事务组（tx-service-group）和服务发现机制实现高可用，支持主流程务注册中心，保障分布式环境下的可靠协调。其核心优势包括协议/存储无关性、高性能、灵活的事务模式选择，可适配微服务架构下的多样化需求。