第二大脑

主题

2026-08-24
798
2.8m

概念卡片：分布式事务与 Seata ​

一句话机制：单机事务靠 ACID，但「下单 + 扣库存 + 扣余额」跨多个服务/数据库时，ACID 无法保证「要么全成、要么全败」；Seata 用 TC（事务协调者）+ TM（事务管理器）+ RM（资源管理器） 三角色，把多个分支事务组合成一个全局事务统一提交或回滚。

为什么单机 ACID 不够用 ​

单机事务满足 ACID（原子性/一致性/隔离性/持久性，靠 Undo Log + 锁/MVCC + WAL）。但服务拆分后，一个业务要跨三个微服务、三个数据库——每个服务的本地事务各自 ACID，整体却无法原子：库存不足时，余额已扣、订单已建，不会回滚。

理论基础：CAP 与 BASE ​

定理内容
CAP一致性 C、可用性 A、分区容错 P 三者不可兼得；P 必然存在 → 只能在 A 和 C 之间取舍
BASE对 CAP 的折中：基本可用 + 软状态 + 最终一致（放弃强一致，接受短暂不一致）

由此得出两种分布式事务思路：AP 模式（各子事务独立提交，事后补偿，最终一致）和 CP 模式（互相等待，同时提交/回滚，强一致但弱可用）。

Seata 三角色 ​

角色全称职责
TCTransaction Coordinator 事务协调者维护全局/分支事务状态，协调提交或回滚
TMTransaction Manager 事务管理器定义全局事务范围，发起提交/回滚
RMResource Manager 资源管理器管理分支事务资源，向 TC 注册并报告状态

四种模式 ​

模式一致性业务侵入说明
AT（默认）最终一致无侵入自动生成反向 SQL 补偿
TCC最终一致有侵入需自己写 Try/Confirm/Cancel
XA强一致无侵入数据库 XA 协议，牺牲可用性
SAGA最终一致有侵入长事务，编排/补偿

不变量（必须成立的约束） ​

  • 分布式事务必须有一个 TC 协调各分支事务，否则无法保证全局一致。
  • 无论哪种模式，都离不开 TC；模式只决定「怎么提交/补偿」。
  • 强一致（XA/CP）代价是弱可用，最终一致（AT/TCC/SAGA/AP）代价是短暂不一致，按业务容忍度选。

踩坑案例 ​

  • 现象：下单成功、库存扣了、余额没扣（或反之），出现「部分成功」。 原因：没接分布式事务，各服务本地事务独立提交。解决：引入 Seata（AT 模式）把跨服务操作纳入全局事务。

常见误解 ​

  • 以为分布式事务能同时满足强一致 + 高可用 → CAP 下只能二选一，Seata 的 AT/TCC 是「最终一致」，不是强一致。
  • 以为所有微服务都要上分布式事务 → 只有「跨服务写且需原子」的场景才需要，否则过度设计。

关联 ​

最近更新