转载 | 分布式系统中的 Saga 模式是什么？
在分布式系统中，微服务为构建可扩展且有弹性的应用程序提供了方法。这些应用程序通常需要多个服务之间的通信来处理单个请求。例如，一个单一请求，如订购产品，可能涉及多个步骤和服务：库存、支付、运输等。这种分布式特性使得确保数据一致性和原子性成为一个复杂的挑战，尤其是当每个服务拥有自己的数据库并独立运行时。如何保证当支付服务成功时，库存得到更新，运输过程启动，同时保持数据完整性？传统的 ACID 事务设计用于具有单一数据库的单体应用程序，在跨多个服务时表现不佳。
What is the Saga Pattern?
Saga 模式是一种设计模式，通过将多个服务之间的事务更新拆分为一系列小的本地事务更新，称为“saga 步骤”或“子事务”，来帮助管理这些事务更新。每个步骤代表与单个服务交互的工作单元。一旦一个步骤完成，它将触发序列中的下一个步骤。如果任何步骤失败，saga 会执行补偿性更新，以撤销前面步骤所做的更改，确保系统返回到其初始状态。
Types of Saga Approaches
实现 Saga 模式主要有两种方法：编排（Orchestration）和编舞（Choreography）。
Orchestration
在这种方法中，由一个中央编排服务负责协调 saga 步骤。编排者告诉每个服务何时执行其本地事务。它维护 saga 的状态，并通过调用补偿事务来处理任何失败。编排者了解整个 saga 流程。
How it works
客户端通过与编排者通信来启动 saga。然后，编排者调用第一个服务。成功完成后，编排者进入下一步骤，调用相应的服务。如果某个服务失败，编排者会按相反顺序触发补偿事务。
Choreography
在编舞方法中，没有中央协调者。相反，参与 saga 的每个服务都知道自己的角色，并通过事件或消息与其他服务进行通信。每个服务监听特定事件，并在收到相应事件时执行本地事务。saga 流程分布在各个服务之间。
How it works
客户端通过与第一个服务通信来启动 saga。该服务执行其事务并发布一个事件。其他监听此事件的服务执行各自的事务并发布它们的事件。这个连锁反应持续进行，直到 saga 完成。如果某个服务失败，它会发布一个补偿事件，触发其他服务执行补偿事务。
Orchestration v/s Choreography
- 编舞没有单点故障，因为每个服务都管理自己在 saga 中的部分。
- 编排通过集中控制提供了简化的错误处理和监控。相比之下，在编舞中，每个服务需要处理自己的错误，这可能导致复杂的错误处理逻辑。
- 在编排中，协调者需要了解 saga 中所有相关的服务，这可能导致紧耦合。相比之下，在编舞中，服务需要就事件和事务的顺序达成一致，这可能导致协调上的开销。
Pros and Cons of Saga Pattern
优点:
- 数据一致性：Saga 模式确保多个服务之间的数据一致性，即使在出现故障时也是如此。
- 可扩展性：它允许可扩展且低耦合的服务，因为每个服务可以独立运行。
- 灵活性：Saga 模式可以处理涉及多个服务和步骤的复杂业务事务。
缺点:
- 复杂性：实现 Saga 模式可能比较复杂，尤其是对于包含许多服务的大型系统。
- 错误处理：管理错误和补偿事务可能具有挑战性，特别是在编舞方法中。
- 性能开销：需要跟踪 saga 的状态并处理补偿事务，这可能会带来性能开销。