1. 课程导论：分布式事务的挑战与Saga模式的诞生背景
1.1 从单体到微服务：事务边界的裂变
在单体应用时代，业务操作通常在一个本地数据库事务中完成，ACID（原子性、一致性、隔离性、持久性）特性由数据库引擎直接保障。然而，当架构演进为微服务后，一个业务请求往往需要跨多个独立服务、多个异构数据库甚至消息队列才能完成。此时，传统本地事务的边界被打破，分布式事务问题随之浮现。
核心矛盾： 微服务架构要求每个服务拥有独立的数据库（Database per Service），但业务一致性却需要跨服务协调。ACID 在分布式环境下无法直接套用，必须寻找新的容错与补偿机制。
1.2 分布式事务的四大核心挑战
在跨服务、跨数据库的场景下，实现数据一致性面临以下关键挑战：
| 挑战维度 | 具体描述 | 典型后果 |
|---|---|---|
| 网络不可靠 | 服务间调用可能超时、重试、乱序或丢失 | 部分服务提交成功，部分失败，数据陷入不一致 |
| 分布式锁与隔离性 | 跨库全局锁性能极低，且容易引发死锁 | 吞吐量骤降，甚至系统雪崩 |
| 协调者单点 | 传统 2PC/3PC 依赖全局协调者（Coordinator） | 协调者宕机导致所有参与者阻塞，资源无法释放 |
| 数据最终一致性 | 业务要求强一致性，但分布式环境只能提供最终一致性 | 业务逻辑复杂化，需要额外补偿与对账机制 |
避坑提示： 许多团队在微服务初期直接套用 2PC（两阶段提交）来解决跨库事务，结果在高并发场景下频繁出现锁超时、协调者崩溃、数据死锁等问题。2PC 在分布式系统中的可用性缺陷（CAP 理论中的 CP 倾向）是引入 Saga 模式的核心驱动力之一。
1.3 传统方案的局限性：为什么 2PC 不够用？
两阶段提交（2PC）是分布式事务的经典方案，但其在微服务环境下的短板非常明显：
- 同步阻塞： 第一阶段锁定资源后，所有参与者必须等待协调者的最终指令，期间无法释放锁。
- 单点故障： 协调者崩溃后，参与者既无法提交也无法回滚，只能一直等待或超时。
- 数据不一致风险： 第二阶段如果部分参与者提交成功、部分失败，协调者无法统一回滚已提交的参与者。
- 不适用于长事务： 2PC 假设事务执行时间极短，但微服务调用链可能涉及人工审批、第三方支付回调等长时间操作。
这些局限性促使架构师寻找一种 无锁、异步、容错 的分布式事务解决方案——Saga 模式应运而生。
1.4 Saga 模式的诞生背景与核心思想
Saga 模式最早由 Hector Garcia-Molina 和 Kenneth Salem 在 1987 年的论文《Sagas》中提出，最初用于解决长事务（Long Lived Transaction, LLT）在数据库系统中的资源锁定问题。其核心思想是：
- 将一个大事务拆分为多个本地事务（Sub-transaction），每个本地事务都有对应的补偿事务（Compensating Transaction）。
- 放弃全局锁，每个子事务执行完毕后立即提交，释放资源。
- 通过编排或 choreography 协调，如果某个子事务失败，则反向依次执行补偿事务，回滚已提交的操作。
关键洞察： Saga 模式不追求分布式环境下的强一致性（ACID），而是通过补偿机制保证最终一致性（BASE——Basically Available, Soft state, Eventually consistent）。这种设计更贴合微服务架构的容错与弹性需求。
1.5 Saga 模式 vs 2PC：核心差异对比
| 对比维度 | 2PC（两阶段提交） | Saga 模式 |
|---|---|---|
| 一致性模型 | 强一致性（CP） | 最终一致性（BASE） |
| 资源锁定 | 全局锁，阻塞等待 | 无锁，每个子事务立即提交 |
| 协调方式 | 中心化协调者 | 编排（Orchestration）或 choreography |
| 容错能力 | 协调者单点故障导致阻塞 | 通过补偿事务实现自动回滚 |
| 适用场景 | 短事务、低并发、强一致性要求 | 长事务、高并发、可接受最终一致性 |
| 典型实现 | XA 协议、Seata AT | 事件驱动、消息队列、状态机 |
1.6 分布式事务演进路线图（SVG）
下图展示了从单体事务到 Saga 模式的演进路径，以及各方案在一致性、可用性、性能之间的权衡：
1.7 事件风暴与 Saga 的集成价值
本课程的核心在于将 事件风暴（Event Storming） 这一协作建模技术引入 Saga 模式的设计过程。传统 Saga 设计往往依赖架构师个人经验，缺乏系统化的可视化方法。事件风暴画布能够：
- 显式化领域事件： 通过事件风暴识别出每个子事务的触发事件、完成事件和补偿事件。
- 可视化补偿流程： 在画布上直观展示正向流程与补偿回滚路径，避免遗漏补偿逻辑。
- 对齐业务与技术： 业务专家与技术团队在同一张画布上协作，减少沟通偏差。
- 生成状态机模型： 从事件风暴画布直接推导出 Saga 状态机，加速代码实现。
课程定位： 本课程不是单纯讲解 Saga 理论，而是提供一套从事件风暴建模到 Saga 代码落地的完整方法论与工具链。你将学会如何用画布设计、验证和交付可靠的分布式事务方案。
1.8 本章小结
分布式事务是微服务架构中无法回避的复杂性来源。传统 2PC 方案在可用性和性能上的缺陷，催生了以补偿机制为核心的 Saga 模式。Saga 通过拆分事务、放弃全局锁、引入补偿操作，实现了高并发场景下的最终一致性。而事件风暴画布的引入，则为 Saga 设计提供了系统化的可视化建模手段，这正是本课程的核心价值所在。