面经策

什么是 Seata？ ​

  • 标签：Seata、微服务、Spring Cloud、后端

🏛 业务架构师 ​

Seata 是开源分布式事务框架，架构三件套：TC（事务协调器，独立部署）、TM（事务管理器，发起方）、RM（资源管理器，参与方）。四种模式按侵入度与一致性取舍：

  • AT（主打）：业务零侵入——代理数据源自动记录前后镜像（undo log），失败自动反向补偿。开发成本最低，但有全局锁，热点行高并发下排队明显；
  • TCC：手动 Try/Confirm/Cancel 三接口——一致性强、性能好，开发量翻倍，留给资金链路；
  • SAGA：长事务状态机编排 + 逆向补偿——流程长的跨企业协作；
  • XA：数据库原生两阶段——强一致但同步阻塞，低频操作用。

业务视角的评估与选型立场：

  1. Seata AT 的最佳场景是存量系统改造：老系统拆微服务后跨库写要保一致，逐个改造成本高——AT 让业务代码不动就获得"看起来像本地事务"的分布式事务，改造成本最低的路径；
  2. 新系统我不首选 Seata：更优先"本地消息表/事务消息 + 幂等 + 对账"的最终一致——便宜、可观测、故障时可人工介入（消息肉眼可见），Seata 的全局事务状态在 TC 里，排障门槛高；高并发下 AT 的全局锁也容易成为热点；
  3. 用 Seata 的纪律：全局事务要小（别包 RPC 长链路）、@GlobalTransactional 边界清晰、TC 集群高可用（协调器单点=全部事务卡死）、undo log 表纳入容量规划。

一句话：Seata 把分布式事务从"每个团队手写补偿"变成"框架级商品"，为存量系统省下大笔改造费；但最终一致 + 对账仍是业务侧的标配兜底——框架降低难度，不消灭本质复杂度。

🏗 系统架构师 ​

Seata 是开源的分布式事务框架（阿里孵化），目标是让微服务间的跨库事务像本地事务一样简单。我按"架构组件 + 三种模式 + 选型"讲：

核心组件：

  • TC（Transaction Coordinator）：独立的事务协调器，维护全局事务状态，驱动提交/回滚——全局事务的"大脑"，要独立集群部署；
  • TM（Transaction Manager）：发起方，定义全局事务边界（@GlobalTransactional 开启/提交/回滚）；
  • RM（Resource Manager）：参与方，管理分支事务，向 TC 注册并上报状态。

三种事务模式：

  • AT（自动补偿，默认）：一阶段本地事务直接提交，RM 自动记录前后镜像（undo log）；全局回滚时按镜像自动生成反向 SQL 补偿；靠全局锁防止脏写。对业务零侵入，开发体验最好，性能适中——一般微服务首选；
  • TCC：业务手写 Try/Confirm/Cancel 三接口，无 undo 依赖、性能好，但要处理幂等、空回滚、悬挂三大坑，侵入大——资金核心场景用；
  • Saga：长流程编排 + 逆向补偿，适合跨系统长事务（无锁高并发），只保最终一致；
  • XA：强一致，性能差，依赖数据库 XA 支持，很少用。

我的实践：订单-库存-账务场景用 AT 起步（@GlobalTransactional 一行注解），性能瓶颈点（高频扣减）下沉 TCC；TC 集群高可用 + 全局事务监控大盘是上线必备。选型认知：Seata 降低的是分布式事务的"接入成本"，一致性与性能的物理权衡没有消失——先问业务能不能用最终一致（消息表），再决定上不上 Seata。

💻 全栈开发专家 ​

Seata = 开源的分布式事务框架，把"跨服务/跨库事务"从手工对账编程变成框架托管。三个角色：

text
TM（事务发起方，业务服务里 @GlobalTransactional）
RM（事务参与者，每个操作 DB 的服务）
TC（事务协调器，独立部署的 seata-server）

AT 模式（主推，近乎零侵入）：

java
@GlobalTransactional(timeoutMills = 60000, name = "create-order")
public void createOrder(OrderDTO dto) {
    orderSvc.create(dto);     // 订单库
    stockSvc.deduct(dto);     // 库存服务（另一个库）
    pointSvc.add(dto);        // 积分服务
}

原理：Seata 代理数据源，执行业务 SQL 时自动生成前后镜像写入 undo_log；一阶段直接提交本地事务并释放锁；二阶段全局提交则异步删 undo_log，回滚则按镜像反向补偿。配合全局锁防脏写。

其他模式：TCC（手写三接口，性能好，资金场景）、SAGA（长事务编排）、XA（强一致，慢）。

我的实战经验（踩坑点）：

  1. undo_log 表每个业务库都要建，忘了会莫名失败；
  2. 全局锁竞争：热点行（爆款商品扣减）在 AT 下会互相等全局锁，高并发场景 AT 会成为瓶颈——热点操作前移到 Redis，或该链路改 TCC；
  3. @GlobalTransactional 的回滚只覆盖发起方能感知的异常，下游异步/消息链路仍要幂等；
  4. seata-server 本身要高可用（DB 存储模式 + 集群），它是新依赖，容量规划别漏。

选型定位：需要"尽量快上线 + 大部分强一致语义"用它；吞吐极限场景还是本地消息表最终一致。