1. 课程导入
在金融系统中，一笔转账、一次支付、一个理财申购，往往横跨账户、账务、清算、风控、通知等多个服务。单体时代靠数据库本地事务就能保证的“要么全成功、要么全回滚”，在微服务与分库分表之后被彻底打破。分布式事务因此从“可选优化”变成“必须掌握的基础能力”。本课程不空谈理论，而是围绕金融场景，把 Saga、TCC、Outbox 三种主流方案讲透、写实、跑通。
一、学习目标：从“知道名词”到“能落地选型”
本课程的学习目标分为四个层次，层层递进：
- 认知层：理解分布式事务的本质矛盾——CAP、BASE 与金融强一致诉求之间的张力，能说清 2PC、3PC 为何在金融高并发场景中受限。
- 原理层：掌握 Saga 的正向补偿与反向回滚、TCC 的 Try-Confirm-Cancel 三阶段、Outbox 的本地事务+消息表+投递器机制。
- 实战层：能基于 Spring Cloud、Seata、RocketMQ 或自研框架，完成跨服务转账、订单支付、积分发放等场景的编码与联调。
- 治理层：具备幂等、空回滚、悬挂、对账、补偿重试、事务日志追踪等生产级问题的排查与设计能力。
一句话概括目标：学完后，你能在评审会上明确说出“这个场景该用 TCC 还是 Saga，为什么不用 2PC，Outbox 放在哪一层”，并给出可执行的补偿与对账方案。
二、核心挑战：金融分布式事务为什么难
金融场景对事务的要求远高于普通电商。它不是“最终一致就行”，而是“钱不能错、账不能乱、监管能审计”。核心挑战集中在以下五点：
- 一致性与可用性的取舍：强一致往往意味着锁与阻塞，高并发下会拖垮核心链路；最终一致又要求业务能接受短暂中间态。
- 网络不确定性：超时不是失败，可能是成功但响应丢失。重试、幂等、悬挂由此成为必答题。
- 补偿逻辑的复杂性：正向业务容易写，反向补偿要考虑“补偿失败怎么办”“补偿本身是否幂等”“空回滚如何识别”。
- 数据可见性与隔离：中间态数据被其他服务读到，可能引发重复扣款、超卖、重复发放。
- 可观测与审计：监管要求每笔资金流转可追溯，事务日志、补偿记录、对账差异必须完整留存。
常见误区：把分布式事务当成“框架一接就完事”。实际上，Seata、RocketMQ 事务消息只解决协调与投递，业务幂等、补偿语义、对账兜底仍必须由研发自己设计。框架是骨架，业务补偿才是血肉。
三、课程整体框架：三方案 + 一治理 + 多场景
课程共 30 章，按“原理—实战—治理—复盘”四段推进。三种方案不是并列罗列，而是按金融场景的适用边界展开：
| 方案 | 核心机制 | 适用场景 | 主要代价 |
|---|---|---|---|
| Saga | 长事务拆分为本地事务链，失败时反向补偿 | 流程长、参与方多、可容忍中间态，如开户、授信 | 无隔离，需补偿设计 |
| TCC | Try 预留资源，Confirm 确认，Cancel 释放 | 资金扣减、库存冻结等强预留场景 | 侵入性强，需三套接口 |
| Outbox | 本地事务写业务表+消息表，投递器异步发送 | 最终一致的通知、积分、账务异步落库 | 投递延迟，需幂等消费 |
治理部分贯穿始终：幂等键设计、事务状态机、补偿重试策略、对账与差异处理、链路追踪与告警。最后通过转账、支付、理财申购三个综合案例做复盘，把三种方案组合使用。
四、实战路线图：从环境到上线的六步
为了让学习可执行，课程给出统一的实战路线。每一步都有可运行的代码与验证方式：
- 环境准备：搭建 Nacos、Seata Server、RocketMQ、MySQL 分库分表环境，统一版本与配置。
- 场景建模：以“账户 A 扣款、账户 B 入账、积分发放、通知推送”为贯穿案例，画出服务边界与事务边界。
- Saga 编码：实现正向服务链与补偿接口，接入状态机，验证失败回滚与重试。
- TCC 编码：实现 Try 冻结、Confirm 扣减、Cancel 解冻，重点处理空回滚与悬挂。
- Outbox 编码：业务表与消息表同库同事务写入，投递器扫描发送，消费端幂等。
- 治理与压测：注入超时、重复、乱序故障，观察补偿、对账、告警是否闭环。
# 典型验证命令：查看 Seata 全局事务状态
curl http://localhost:7091/api/v1/globalSession/query \
-H "Content-Type: application/json" \
-d '{"xid":"192.168.1.10:8091:1234567890"}'
# 预期返回片段
{
"xid": "192.168.1.10:8091:1234567890",
"status": "Committed",
"branchSessions": [
{"branchId": 1001, "resourceId": "jdbc:mysql://db_account", "status": "Committed"},
{"branchId": 1002, "resourceId": "jdbc:mysql://db_point", "status": "Committed"}
]
}学习建议：每学完一种方案，先画事务边界图，再写补偿逻辑，最后做故障注入。不要跳过“失败路径”的编码，金融系统的价值恰恰体现在异常处理上。
本章作为导入，已经明确了目标、挑战、框架与路线。接下来将从分布式事务的理论根基讲起，逐步进入三种方案的原理与代码实战。请带着一个问题开始：你当前系统里，哪一笔业务最怕“扣了钱没到账”？把它记下来，它将成为你贯穿全课程的实战靶子。