本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Saga 编配模式
## 意图
通过使用事件订阅，saga 编排模式有助于在跨多个服务的分布式事务中保持数据完整性。在分布式事务中，可以在事务完成之前调用多项服务。当服务将数据存储在不同的数据存储中时，要维护这些数据存储之间的数据一致性可能会很困难。
## 动机
*事务*是一个可能涉及多个步骤的单个工作单元，其中要么完全执行所有步骤，要么不执行任何步骤，从而使数据存储保持其一致状态。术语*原子性、一致性、隔离和持久性（ACID）*定义了事务的属性。关系数据库提供 ACID 事务以维护数据一致性。
为了维护事务的一致性，关系数据库使用两阶段提交（2PC）方法。这包括“准备阶段”**和**“提交阶段”。
+ 在准备阶段，协调过程要求事务的参与进程（参与方）承诺要么提交事务，要么回滚事务。
+ 在提交阶段，协调过程会要求参与方提交事务。如果参与方不同意在准备阶段提交，则事务将被回滚。
在遵循 database-per-service设计模式的分布式系统中，两阶段提交不是一种选择。这是因为每个事务分布于不同的数据库中，并且没有单个控制器可以协调类似于关系数据存储中两阶段提交的过程。在这种情况下，一种解决方案是使用 saga 编配模式。
## 适用性
在以下情况下使用 saga 编配模式：
+ 您的系统要求在跨多个数据存储的分布式事务中保持数据完整性和一致性。
+ 数据存储（例如，NoSQL 数据库）没有 2PC 提供 ACID 事务，您需要在单个事务中更新多个表，而在应用程序边界内实现 2PC 将是一项复杂的任务。
+ 管理参与方事务的中央控制过程可能会成为单点故障。
+ saga 的参与方是独立的服务，需要松耦合。
+ 业务域中的有界上下文之间存在通信。
## 问题和注意事项
+ **复杂性：**随着微服务数量的增加，由于微服务之间的交互次数众多，saga 编配可能变得难以管理。复杂性：补偿性事务和重试会增加应用程序代码的复杂性，从而提升维护开销。当 saga 中只有数个参与方，并且您需要一个没有单点故障的简单实施时，编配是合适的。当添加更多参与方时，使用这种模式跟踪参与方之间的依赖关系就会变得比较困难。
+ **弹性实施：**在 saga 编配中，与 saga 编排相比，在全局范围内实施超时、重试和其他弹性模式更加困难。编配必须在单个组件上实现，而不是在编排工具级别上实现。
+ **循环依赖项：**参与方使用彼此发布的消息。这样可能会导致循环依赖项，从而让代码变得复杂并带来维护开销，还可能导致死锁。
+ **双写问题：**微服务必须以原子方式更新数据库和发布事件。任何一个操作失败都可能导致状态不一致。解决这个问题的一种方法是使用[事务发件箱模式](transactional-outbox.md)。
+ **保存事件：**saga 参与方根据发布的事件行动。出于审计、调试和重播目的，按照事件发生的顺序来保存事件非常重要。您可以使用[事件溯源模式](event-sourcing.md)将事件保留在事件存储中，以应对为恢复数据一致性需要重播系统状态的情况。事件存储也可用于审计和故障排除目的，因为它们反映了系统中的每一个更改。
+ **最终一致性**：本地事务的顺序处理可实现最终一致性，这对于需要强一致性的系统来说可能是挑战。您可以通过设定业务团队对一致性模型的期望，或重新评估用例并切换到提供强一致性的数据库来解决此问题。
+ **幂等性**：Saga 参与方必须具有幂等性，以便在意外崩溃和编排工具故障导致暂时性故障时允许重复执行。
+ **事务隔离**：saga 模式缺少事务隔离，事务隔离是 ACID 事务中的四个属性之一。事务的[隔离程度](https://docs.aws.amazon.com/neptune/latest/userguide/transactions-isolation-levels.html)决定了其他并发事务对该事务所操作的数据的影响程度。事务的并行编排可能会导致数据陈旧。建议使用语义锁定来处理此类场景。
+ **可观测性**：可观测性是指详细的日志记录和跟踪，以排查实施和编排过程中的问题。当传奇参与者的数量增加导致调试变得复杂时，这一点就变得重要了。 End-to-end与传奇编排相比，在传奇编舞中更难实现监测和报告。
+ **延迟问题**：当 saga 由几个步骤组成时，补偿性事务可能会增加整体响应时间的延迟。如果事务进行同步调用，则这样会进一步增加延迟。
## 实施
### 高级架构
在下面的架构图中，saga 编配有三个参与方：订单服务、库存服务和付款服务。完成事务需要三个步骤：T1、T2 和 T3。三个补偿事务将数据恢复到初始状态：C1、C2 和 C3。
![\[Saga 编配高级架构\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/cloud-design-patterns/images/saga-choreography-1.png)
+ 订单服务运行本地事务 T1，该事务以原子方式更新数据库并向消息代理发布 `Order placed` 消息。
+ 库存服务订阅了订单服务消息，并收到已创建订单的消息。
+ 库存服务运行本地事务 T2，该事务以原子方式更新数据库并向消息代理发布 `Inventory updated` 消息。
+ 付款服务订阅了来自库存服务的消息，并收到已更新库存的消息。
+ 付款服务运行本地事务 T3，该事务以原子方式向数据库更新付款详情，并向消息代理发布 `Payment processed` 消息。
+ 如果付款失败，支付服务将运行补偿事务 C1，该事务以原子方式恢复数据库中的付款信息，并向消息代理发布 `Payment failed` 消息。
+ 运行补偿事务 C2 和 C3 以恢复数据一致性。
### 使用亚马逊云科技服务来实施
您可以使用 Amazon 实现传奇编舞模式。 EventBridge EventBridge 使用事件来连接应用程序组件。它通过事件总线或管线处理事件。事件总线是接收[事件](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)，并将其传送到零个或多个目的地（或*目标*）的路由器。[与事件总线关联的规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)会在事件到达时进行评估，并将其发送到[目标](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)进行处理。
在以下架构中：
+ 微服务（订单服务、库存服务和付款服务）作为 Lambda 函数实施。
+ 有三种自定义总 EventBridge 线：`Orders`事件总线、`Inventory`事件总线和`Payment`事件总线。
+ `Orders` 规则、`Inventory` 规则和 `Payment` 规则匹配发送到相应事件总线的事件并调用 Lambda 函数。
![\[使用亚马逊云科技服务的 Saga 编配架构\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/cloud-design-patterns/images/saga-choreography-2.png)
在成功的场景中，下订单时：
1. 订单服务处理请求并将事件发送到 `Orders` 事件总线*。*
1. 这些 `Orders` 规则与事件相匹配并启动库存服务*。*
1. 库存服务更新库存并将事件发送到 `Inventory` 事件总线。
1. `Inventory` 规则与事件相匹配并启动付款服务。
1. 付款服务处理付款并将事件发送到 `Payment` 事件总线。
1. `Payment` 规则匹配事件并将 `Payment processed` 事件通知发送给侦听器。
或者，当订单处理出现问题时， EventBridge 规则会启动补偿性交易，以恢复数据更新，以保持数据的一致性和完整性。
1. 如果付款失败，则 `Payment` 规则会处理该事件并启动库存服务*。*库存服务部门运行补偿事务以恢复库存。
1. 库存恢复后，库存服务会将 `Inventory reverted` 事件发送到 `Inventory` 事件总线*。*此事件由 `Inventory` 规则处理*。*它启动订单服务*，*该服务运行补偿事务以删除订单。
## 相关内容
+ [Saga 编排模式](saga-orchestration.md)
+ [事务发件箱模式](transactional-outbox.md)
+ [使用退避模式重试](retry-backoff.md)