分布式事务场景与 Seata 总览
Seata 系列 · 第 1/8 篇
下一篇：《Seata AT 模式：角色、两阶段与 XA 对比》
开头：本地事务够用了，为什么又冒出「分布式事务」？
单体应用里，一个 @Transactional 就能保证「要么全成功、要么全回滚」。业务拆成微服务、数据拆成多个库之后，一次用户操作往往要跨多个数据库、跨多次 RPC 调用——本地事务管不到边界之外，分布式事务问题就出现了。
本文从典型场景出发，说明问题怎么产生，并给出 Seata 在 Spring Cloud Alibaba 生态中的定位。AT 模式的细节放在 第 2 篇，环境搭建见 第 3 篇。
一、什么情况下会产生分布式事务？
一句话概括：
一次业务操作需要跨多个数据源，或需要跨多个系统远程调用，就会产生分布式事务问题。
1.1 经典例子：银行转账
需求：银行有两个客户张三和李四，要把张三账户的 1000 元转到李四账户。
约束：不能出现中间态——张三已扣款而李四未到账，或反之。
若两人数据在同一个数据库，Spring 的 @Transactional 即可保证 ACID。问题在于业务规模扩大后，数据不可能永远落在一个库里。
1.2 分库分表：水平分割倒逼分布式事务
用户量从百万到千万、上亿，单表、单库无法承载，必然走向分库分表。不同用户可能落在不同数据库实例上，原来「一个库内的事务」变成跨库事务，@Transactional 失效。
这就是跨数据库的分布式事务问题：每个库各自能提交，但全局没有统一协调者。
1.3 微服务化：服务拆分倒逼分布式事务
更常见的情形是微服务架构。单体应用内部无论调用多少层，最终都在同一数据源上完成业务：
拆成订单、支付、账务等多个服务后，每个服务使用独立数据源，甚至部署在不同机房。一次转账可能依次：
- 交易系统创建订单；
- 支付系统记录明细；
- 账务系统 A 扣款；
- 账务系统 B 加款。
每个服务内部仍可用本地事务保证一致性，但整条业务链如何保证？这就是跨服务的分布式事务问题。
1.4 实战背景：高并发秒杀的分库架构
高 QPS 秒杀场景下，库存、订单往往分属不同库（甚至不同服务）。一次「扣库存 + 下订单」必须全局一致，否则会出现超卖或空单——这正是本系列后续 AT 实战的动机（架构图见 第 2 篇）。
二、Seata 是什么？
Seata（Simple Extensible Autonomous Transaction Architecture）是 Apache 开源的分布式事务解决方案，Spring Cloud Alibaba 将其作为默认推荐组件。
Seata 的设计初衷有两点：
| 目标 | 含义 |
|---|---|
| 对业务无侵入 | 尽量不让开发者为了事务改造业务代码 |
| 高性能 | 避免传统 2PC/XA 长时间锁资源带来的吞吐下降 |
2.1 两种主流模式：AT 与 TCC
| 模式 | 关注点 | 业务侵入 |
|---|---|---|
| AT | 多 DB 访问的数据一致性（含多服务多 DB） | 小：代理数据源 + 全局事务注解 |
| TCC | 按业务横向拆资源、微服务间调用一致性 | 较大：Try / Confirm / Cancel 三套逻辑 |
- AT：本系列第 1–4 篇重点，适合「下单扣库存」类 CRUD 场景。
- TCC：第 5–7 篇展开，适合需要精细控制资源预留的业务。
三、Seata 架构速览：TC / TM / RM
在深入 AT 两阶段之前，先认识三个角色（与 第 2 篇 一致）：
| 角色 | 全称 | 职责 |
|---|---|---|
| TC | Transaction Coordinator | 维护全局事务状态，驱动全局提交或回滚 |
| TM | Transaction Manager | 定义全局事务边界，发起全局提交/回滚决议 |
| RM | Resource Manager | 管理分支事务：注册、上报、执行本地提交/回滚 |
典型调用链：
- TM 向 TC 申请开启全局事务，TC 生成全局唯一 XID；
- XID 随 RPC 调用链传递到各微服务；
- 各 RM 向 TC 注册分支事务，纳入该 XID；
- TM 请求 TC 对 XID 提交或回滚；
- TC 协调该 XID 下所有分支一并提交或回滚。
四、本系列阅读路线
| 篇次 | 主题 |
|---|---|
| 01（本文） | 场景与 Seata 总览 |
| 02 | AT 模式：两阶段、undo_log、与 XA 对比 |
| 03 | 搭建 TC：file/db 存储、Nacos 集群 |
| 04 | TM/RM 接入、undo_log、秒杀实战 |
| 05–08 | TCC 实战、常见问题、源码、隔离性与面试 |
小结
- 分库分表和微服务拆分是分布式事务的两个主要来源。
- Seata 在「无侵入 + 高性能」目标下提供 AT（多 DB）与 TCC（业务拆分）两种路径。
- 全局协调靠 TC，边界由 TM 划定，RM 执行各分支的本地事务与回滚。
下一篇从 AT 模式的两阶段提交、undo_log 机制以及与经典 XA 的差异讲起。