什么是 Seata？

【核心定义】
Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务，其核心本质是通过 TC（事务协调器） 统一协调多个微服务的本地事务，保证全局事务的 ACID 特性。

【关键要点】

核心角色：
- TC（Transaction Coordinator）：事务协调器，独立部署，负责全局事务的开启、提交或回滚的决策与调度。
- TM（Transaction Manager）：事务管理器，嵌入在业务应用中，负责定义全局事务的边界（如 @GlobalTransactional 注解）。
- RM（Resource Manager）：资源管理器，管理分支事务，负责向 TC 注册分支事务、报告状态，并执行 TC 的提交或回滚指令。
事务模式：
- AT 模式（默认）：基于两阶段提交（2PC）的增强版，通过全局锁 + 数据快照（undo_log）实现自动补偿，对业务代码零侵入。
- TCC 模式：通过 Try、Confirm、Cancel 三个阶段由业务代码手动实现资源预留和补偿，适用于高一致性要求的场景（如金融账户）。
- Saga 模式：长事务解决方案，通过事件/状态机驱动每个服务的正向操作与反向补偿，适用于业务流程长、可补偿的业务。
- XA 模式：基于数据库原生 XA 协议的两阶段提交，强一致但资源锁定时间长，性能较低。
核心流程（以 AT 模式为例）：
- 第一阶段：各分支事务执行后，生成数据快照（前置镜像 + 后置镜像）存入 undo_log 表，并向 TC 注册分支事务状态。
- 第二阶段：TC 根据全局事务结果决定提交或回滚。提交时异步删除 undo_log；回滚时根据 undo_log 中的前置镜像恢复数据。

【深度推导/细节】

全局锁防脏写：AT 模式在更新数据前会尝试获取全局锁（TC 维护），若获取失败（其他全局事务正在修改同一行），则分支事务回滚，避免脏写。
性能优化点：
- 异步提交：第二阶段提交时仅删除 undo_log，无需等待网络确认，提升吞吐量。
- 锁优化：全局锁粒度细化到数据行，减少锁冲突；支持本地锁（如 MySQL 行锁）与全局锁的协同。
高可用设计：TC 支持集群部署，基于 Raft 协议选举 Leader，事务日志持久化到数据库或文件，故障时可恢复。

【关联/对比】

『面试官追问』

AT 模式 undo_log 表结构及回滚原理
- 表字段：id（主键）、branch_id（分支事务ID）、xid（全局事务ID）、rollback_info（序列化的前后镜像数据）、log_status（状态）。
- 回滚时，根据 xid 和 branch_id 查询 undo_log，解析 rollback_info 中的前置镜像，生成反向 SQL 执行恢复。
全局锁如何避免死锁？
- TC 检测锁等待超时（默认 10 秒），超时后主动中断后申请锁的事务，抛出 LockConflictException 触发回滚。
TCC 模式空回滚和幂等性问题如何解决？
- 空回滚：Try 阶段未执行时 Cancel 被调用，需通过事务控制表记录 Try 状态，若未执行则跳过 Cancel 操作。
- 幂等性：每个分支事务记录状态（try/comfirm/cancel），重复调用时根据状态判断是否执行。
Seata 性能瓶颈及优化
- 瓶颈：TC 单点压力（全局锁管理、日志持久化）。
- 优化：TC 集群化、undo_log 异步清理、分库分表下减少全局锁竞争（业务设计避免热点数据）。
版本差异（如 1.x vs 2.x）
- 1.x：AT 模式依赖数据库行锁，TC 高可用需自行实现。
- 2.x：引入全局锁服务独立部署，支持 Redis 等作为锁存储；TC 默认集成 Raft 协议实现高可用；支持 Seata Server 控制台可视化监控。

【总结】
Seata 通过 TC/TM/RM 三层架构解耦事务协调与业务逻辑，提供 AT、TCC、Saga、XA 四种模式适应不同场景，核心在于全局锁与 undo_log 机制保障一致性，同时通过异步化、锁优化提升性能，是微服务分布式事务的工业级解决方案。

# 什么是 Seata？