编排式 Saga（基线方案）
使用场景: 为微服务添加分布式事务的团队
一个中央编排器驱动每一步
编排器调用服务、收到响应、决定下一步
失败时编排器反向跑补偿
Saga 状态存在编排器中
比协作式更易追踪和调试
这样组织的原因: 编排式 Saga 是最容易上手的——图表有一个清晰的协调者拥有 Saga 状态，任何失败都能追溯到某个具体的编排器决策，而不必跨服务追事件链。
真实案例
协作式 Saga（事件驱动）
使用场景: 已使用事件总线的团队
无中央协调者——服务对事件做反应
OrderPlaced → Payment 监听、扣款、发出 PaymentSucceeded
PaymentSucceeded → Inventory 监听、预扣、发出 InventoryReserved
失败事件触发补偿处理器
Saga 状态分布在各服务中
这样组织的原因: 协作式以可追踪性为代价去掉编排器——图表展示事件链而非中央驱动者，扩展性好但调试更难，因为 Saga 状态隐含在事件流里。
带超时和重试的 Saga
使用场景: 优雅处理临时失败的团队
每步有重试策略（如 3 次带退避）
每步有超时（之后视为失败）
持久化的步骤状态在编排器重启后存活
超时触发补偿，而非单纯重试循环
幂等键防止重试时产生重复效果
这样组织的原因: 真实的 Saga 需要超时和重试——图表在每步箭头上标注这些策略，因为没有它们，网络抖动会让 Saga 卡死；没有幂等，重试会变成重复扣款。
并行 Saga 分支
使用场景: 某些步骤可并行执行的团队
编排器分叉：如「通知客户」+「更新分析」并行
两条分支都成功才继续
任一分支失败触发补偿
减少 Saga 总延迟
比串行更难推理
这样组织的原因: 并行分支在步骤独立时降低延迟——图表在正向路径中展示分叉 / 合并，任一分支失败时触发补偿，用复杂度换速度。
使用技巧
- 始终把补偿路径作为正向路径下方的独立行——视觉分离正是 Saga 图的核心价值。
- 标注每个补偿撤销的是哪个正向步骤；这里的歧义是 Saga 设计最常见的 bug。
- 用虚线箭头画「失败时」边、用实线画 happy path——读者一眼就能看出成功 / 失败两条流。
- 如果画超时和重试，把它们放在正向箭头上；策略就住在那里。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=saga-pattern-architecture
编辑此 Saga 模板