分布式事务 saga 模式的特点是什么

想要搞懂分布式系统面试，Saga模式几乎是绕不开的经典问题。今天咱们就以一线码农的视角，掰开了揉碎了聊聊它的核心特点，让你在面试中游刃有余。

📁 备战面试必备资源：2025年Java面试宝典
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g{.blue} 提取码: 9b3g

🔍 特点一：事件驱动的长事务拆分

分布式事务的核心难点就在于“长”。Saga模式聪明地把一个大的分布式事务，拆解成一个个按顺序执行的小本地事务。这些小事务被称为“参与事务”或者干脆叫“子事务”。

想象你网购下单这个分布式事务场景，拆解后可能是：

创建订单（订单服务）
扣减库存（库存服务）
扣款（支付服务）

Saga模式依靠事件（通常是消息队列）来驱动这些子事务的执行。每个子事务完成后，会触发下一个子事务的执行指令。这种事件驱动的分布式事务处理方式，天然适合微服务架构的异步通信特性，是Saga设计的精髓。

🔄 特点二：明确的补偿机制（正向操作+反向操作）

这可是Saga模式处理分布式事务的灵魂所在！每个子事务除了实现业务逻辑（正向操作），都必须预先定义好一个对应的补偿操作（也叫回滚操作）。

补偿操作不是数据库那种简单回滚，它需要根据正向操作的结果，执行一个业务语义上的撤销。比如：

正向操作：扣减库存。补偿操作：增加库存（可能需要带上订单号等上下文）。
正向操作：创建订单。补偿操作：取消/标记订单无效。
正向操作：扣款。补偿操作：退款。

当某个子事务执行失败时，Saga事务协调器（可能内嵌在服务中或用独立组件）就会启动补偿流程，按已完成的子事务的逆序，逐个调用它们的补偿操作，将系统状态“回滚”到事务开始前的样子（业务上尽力接近）。正是这种显式的补偿机制，避免了分布式事务中常见的资源长时间锁定问题。

⚙ 特点三：避免强锁，拥抱最终一致性

与2PC（两阶段提交）等依赖资源管理器在准备阶段加锁的模式处理分布式事务不同，Saga模式在执行子事务时通常不长时间锁定资源（比如数据库行锁）。

在正向执行流程中：

每个子事务独立提交，释放本地资源锁。
事务的整体状态由应用层逻辑（Saga协调器）管理，而不是数据库的全局锁。

这极大提高了分布式事务系统的并发能力和吞吐量，减少了死锁风险。当然，代价就是牺牲了强一致性（Strong Consistency），整个Saga事务执行过程中（正向流程和可能的补偿流程期间），系统会处于中间状态，但最终（当所有操作成功或补偿完成后）会达到一致性状态。Saga模式追求的是最终一致性，这对很多业务场景（如电商、支付）是完全可接受的。

🧩 特点四：分布式事务的编排与执行

Saga模式需要一种方式来定义子事务的执行顺序以及如何处理失败。这通常通过两种Saga模式实现：

编排式（Choreography）：
- 没有中央协调器。
- 每个服务监听前一个服务发出的事件，执行自己的事务，然后触发下一个事件。
- 补偿也由服务监听到失败事件后自行触发。
- 特点：松耦合，但流程分散，复杂度较高，调试跟踪困难。
(图示：编排式Saga，事件驱动各服务协作)
编制式（Orchestration）：
- 引入一个中心化的协调器（Saga Orchestrator）。
- 协调器负责按照预定流程（通常是一个状态机）依次调用各个服务的接口。
- 协调器负责监控执行结果，并在失败时发起补偿流程。
- 特点：逻辑集中，流程清晰，易于管理和监控，但引入了单点（协调器）依赖。
(图示：编制式Saga，中央协调器驱动流程)