本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Saga 模式
*Saga* 由一系列本地事务组成。saga 中的每个本地事务都会更新数据库，并触发下一个本地事务。如果事务失败，则 saga 将运行补偿事务，以恢复先前事务所做的数据库更改。
通过使用延续和补偿原则，这种本地事务顺序有助于实现业务工作流程。*延续原则*决定工作流程的向前恢复，而*补偿原则*决定向后恢复。如果在事务的任何步骤更新失败，则 saga 会发布一个事件，用于延续（重试事务）或补偿（返回到先前的数据状态）。这样可以确保数据完整性得到维护，并且在数据存储之间保持一致。
例如，当用户从在线零售商处购买图书时，该过程由一系列事务组成，例如订单创建、库存更新、付款和发货，这些事务代表了业务工作流程。为了完成此工作流程，分布式架构会发出一系列本地事务，以便在订单数据库中创建订单、更新库存数据库和更新付款数据库。流程成功后，将依次调用这些事务以完成业务工作流程，如下图所示。但是，如果其中任何一个本地事务失败，则系统应该能够决定适当的下一步 – 即向前恢复或向后恢复。
以下两种场景有助于确定下一步是向前恢复还是向后恢复：
+ 平台级故障，即底层基础设施出现问题并导致事务失败。在这种情况下，saga 模式可以通过重试本地事务并延续业务流程来实现向前恢复。
+ 应用程序级故障，即由于无效付款而导致付款服务失败。在这种情况下，saga 模式可以通过发出补偿事务来更新库存和订单数据库，并将之恢复为先前的状态来执行向后恢复。
saga 模式处理业务工作流程，并确保通过向前恢复达到理想的最终状态。如果出现故障，它会使用向后恢复来还原本地事务，以避免出现数据一致性问题。
saga 模式有两种变体：编配和编排。
## saga 编配
saga 编配模式取决于微服务发布的事件。saga 参与方（微服务）订阅事件并根据事件触发器采取行动。例如，下图中的订单服务会发出一个 `OrderPlaced` 事件。库存服务订阅该事件，并在 `OrderPlaced` 事件发出时更新库存。同样，参与方服务根据所发出事件的上下文行动。
当 saga 中只有几个参与方，并且您需要一个没有单点故障的简单实施时，saga 编配模式是合适的。当添加更多参与方时，使用这种模式跟踪参与方之间的依赖关系就会变得比较困难。
有关详细评述，请参阅本指南的 [saga 编配](saga-choreography.md)部分。
## Saga 编排
saga 编排模式有一个名为*编排工具*的中央协调器。saga 编排工具管理和协调整个事务生命周期。它知道完成事务需要执行的一系列步骤。要运行某个步骤，它会向参与方微服务发送一条消息以执行该操作。参与方微服务完成操作并向编排工具发送一条消息。根据收到的消息，编排工具决定接下来要在事务中运行哪个微服务。
当参与方众多，并且 saga 参与方之间需要松耦合时，saga 编排模式是合适的。编排工具通过使参与方松耦合来囊括逻辑的复杂性。但是，编排工具可能成为单点故障，因为它控制着整个工作流程。
有关详细评述，请参阅本指南的 [saga 编排](saga-orchestration.md)部分。