北京食药局网站年检怎么做网站页面设计说明怎么写
Seata 是一款开源的 分布式事务解决方案，由阿里巴巴中间件团队开发并开源。它的名字是 Session + Transaction 的缩写，意为“一个会话内的事务”，旨在解决微服务架构下跨服务、跨数据库的数据一致性问题。
简单来说，Seata 的核心目标就是让分布式事务像本地数据库事务一样简单易用。
Seata 解决的核心问题
在单体应用中，数据库事务（ACID）可以保证数据一致性。但在微服务架构中：
-
业务被拆分成多个独立服务。
-
每个服务有自己的独立数据库。
-
一个业务操作需要调用多个服务，每个服务执行自己的本地事务。
例如：用户下单操作可能涉及：
-
订单服务：创建订单（本地事务）。
-
库存服务：扣减库存（本地事务）。
-
账户服务：扣减余额（本地事务）。
问题： 如何保证这三个服务的本地事务要么全部成功，要么全部失败回滚？这就是分布式事务问题。传统的数据库事务无法跨越多个独立的数据库。
Seata 的工作原理（核心：AT 模式）
Seata 最常用的是 AT (Automatic Transaction) 模式，其核心思想是两阶段提交（2PC）的改进版，通过全局事务协调器 + 本地事务补偿来实现分布式事务。它包含三个关键角色：
-
Transaction Coordinator (TC - 事务协调器)：
-
Seata 的核心服务器组件（独立部署）。
-
负责全局事务的发起、提交或回滚决策。
-
维护全局事务（XID）和分支事务（Branch ID）的状态。
-
-
Transaction Manager (TM - 事务管理器)：
-
集成在发起全局事务的业务服务中（例如上面的订单服务）。
-
负责定义全局事务的边界（用
@GlobalTransactional注解标记方法）。 -
向 TC 注册全局事务并发起最终的全局提交或回滚请求。
-
-
Resource Manager (RM - 资源管理器)：
-
集成在每个操作本地资源的业务服务中（例如订单服务、库存服务、账户服务）。
-
负责注册分支事务、管理本地事务状态、向 TC 报告分支事务状态。
-
在 AT 模式下，最关键的是：在执行本地 SQL 时，RM 会自动拦截 SQL，生成执行前后的镜像数据（快照）形成 UNDO LOG（回滚日志），并和业务数据的更新操作在同一个本地事务中提交。这是实现自动补偿的关键。
-
AT 模式工作流程（简化版）
-
TM 开启全局事务： TM 向 TC 申请一个全局唯一的
XID。 -
XID 传播： 这个
XID随着微服务调用链（通过 RPC 上下文）传播到所有相关的微服务（RM）。 -
RM 注册分支事务 & 执行业务 SQL：
-
每个 RM 在执行自己的业务 SQL 前，向 TC 注册一个分支事务，绑定到当前的
XID。 -
RM 拦截业务 SQL： 在执行 SQL 前生成查询数据的前置镜像（Before Image），执行 SQL 后生成后置镜像（After Image）。
-
生成 UNDO LOG： 将业务 SQL、前置镜像、后置镜像等信息作为 UNDO LOG 记录。
-
本地事务提交： 将业务数据的更新和 UNDO LOG 写入同一个本地事务中提交。此时数据已修改，但对全局事务来说只是“预提交”。
-
-
TM 决定全局提交/回滚： 所有分支事务都执行成功后（本地事务都提交了），TM 向 TC 发起全局提交请求。
-
TC 通知提交： TC 向所有参与该 XID 的 RM 发送异步的提交指令。
-
RM 清理资源： RM 收到提交指令后，异步删除对应的 UNDO LOG 记录（因为不需要回滚了）。（快速完成）
如果发生失败需要回滚
-
TM 发起全局回滚： 如果任何一个分支事务失败（本地事务失败或业务异常），TM 会向 TC 发起全局回滚请求。
-
TC 通知回滚： TC 根据 XID 找到所有已注册的分支事务，向对应的 RM 发送回滚指令。
-
RM 执行补偿：
-
RM 根据 XID 和 Branch ID 找到对应的 UNDO LOG。
-
校验脏写： 用 UNDO LOG 中的后置镜像（After Image）与当前业务数据比较。如果一致，说明没有脏写，可以安全回滚；如果不一致，根据配置策略处理（如重试、人工干预）。
-
生成补偿 SQL： 根据 UNDO LOG 中的前置镜像（Before Image）生成反向的更新 SQL（回滚 SQL）。
-
执行补偿 SQL： 执行回滚 SQL，将数据恢复到更新前的状态。
-
提交本地事务： 执行回滚 SQL 后提交本地事务。
-
清理资源： 删除 UNDO LOG。
-
-
TC 完成回滚： TC 收到所有分支回滚成功的报告，将全局事务状态标记为已回滚。
Seata 的主要优点
-
对业务侵入性低： AT 模式只需要在全局事务入口添加一个
@GlobalTransactional注解，业务代码几乎无需改造（与本地事务写法类似）。 -
高性能： 大部分情况下，全局提交是异步的、非常快速（只需删除 UNDO LOG）。一阶段本地事务已经提交，释放了数据库锁资源。
-
自动补偿： 基于 UNDO LOG 实现自动回滚，开发者无需手动编写反向补偿逻辑（TCC 模式需要）。
-
支持多种模式： 除了 AT 模式，还支持 TCC、Saga、XA 等模式，适应不同场景。
-
生态支持好： 与 Spring Cloud、Dubbo、gRPC 等主流微服务框架，以及 MySQL、Oracle、PostgreSQL 等常用数据库集成良好。
-
高可用： TC 支持集群部署，保证高可用性。
Seata 的主要模式
-
AT 模式 (Automatic Transaction - 默认/推荐)： 如上所述，基于支持本地 ACID 事务的关系型数据库，通过代理 JDBC 数据源，自动生成 UNDO LOG 实现回滚。最常用。
-
TCC 模式 (Try-Confirm-Cancel)： 需要开发者手动编写 Try、Confirm、Cancel 三个阶段的业务逻辑。适用于对性能要求极高、或者需要与不支持 ACID 事务的资源（如 Redis）交互的场景。侵入性较高。
-
Saga 模式： 长事务解决方案。将一个长流程分解成一系列本地事务。每个本地事务都有对应的补偿事务。如果某个本地事务失败，则按相反顺序执行前面已成功事务的补偿事务。适用于业务流程长、参与者多的场景。
-
XA 模式： 基于数据库原生支持的 XA 协议实现两阶段提交。强一致性最高，但性能最低（持有锁时间长），资源锁定时间长。
典型应用场景
-
电商下单、支付、扣库存、积分等跨服务操作。
-
银行转账（跨账户）。
-
任何涉及多个微服务、多个数据库写操作，且需要保证整体数据一致性的业务场景。
总结
Seata 是一个强大的开源分布式事务中间件，尤其以其 AT 模式的低侵入性、易用性和较好的性能著称。它通过全局事务协调器(TC)、事务管理器(TM) 和资源管理器(RM) 协同工作，利用 UNDO LOG 机制实现自动回滚补偿，有效地解决了微服务架构下的数据一致性问题，是构建可靠分布式系统的关键组件之一。