什么是saga？ 在微服务架构中，每个服务都是独立的数据库，但需要系统中的数据完整性。 saga模式是为了保证系统中数据的完整性而设计的
本论文以订购服务为例来说明saga服务
整个订单生成过程包括四种服务：订单服务(订单生成)、用户服务(验证用户权限)、帐户服务(例如，付费)和厨师服务
Created with Raphal 2.2.0订购流程订购服务创建一个等待批准的订购用户服务，并验证该用户是否可以订购单个帐户服务并执行支付用户费用的批准操作。 厨师服务将订单状态更改为等待受理状态。 订单服务将订单状态更改为接受状态并退出。 saga的两种调整模式在订购过程中。 每一步的成功或失败由saga协调，下一步成功。 如果失败，则必须更改此步骤之前的状态，例如，如果批准状态失败，订单状态将更改为订单生成失败状态。 进行这种协调有协调模式和组织模式两种方式。
协作模型由每个服务自己的saga进行协调，订阅每个服务，通过服务事件返回信息并做出相应的响应。 参与订购流程的每个服务都从订购服务开始(在整个流程中总共有四个事件呈环形，如下图所示)，更新数据库并启动以下相应的服务：
工作流程如下。
订单服务(Order events )创建处于“正在申请”(APPROVAL PENDING )状态的订单并发布“订单创建”(OrderCreated )事件。 用户服务(Consumer service )启动订单创建(OrderCreated )事件，验证消费者是否可以订购，并发布用户验证(user activation )事件。 验证“厨师服务”(Kitchen service )消费(OrderCreated )事件、订单，创建处于“正在创建”(CREATE PENDING )状态的厨师任务Ticket，然后， “TicketCreated”事件帐户服务“Accounting Service”消费订单创建提交“OrderCreated”事件，以进行“PENDING”状态的信用卡验证“credit card auaud” 消费“帐户服务”(Accounting Service ) TicketCreated和用户身份验证)事件，对消费者信用卡计费，发行信用卡身份验证(CreditCardAuthorized )事件厨师服务触发消费信用卡验证事件，将Ticket的状态更改为等待接受状态。 订单服务(Order Service )接收信用卡验证(CreditCardAuthorized )事件，将Order的状态更改为“接受”(APPROVED )，然后接受订单)
协同Saga的好处和弊端的好处：
简单：服务在创建、更新或删除业务对象时发出事件。 松散耦合：参与者订阅事件，因此彼此之间不会产生耦合。 弊端：
晦涩难懂：与排列表达式不同，代码中没有定义Saga的单个位置。 相反，合作型Saga的逻辑分布在各服务器的实现上。 因此，开发人员可能很难理解特定的Saga是如何工作的。 服务之间的循环相关性： Saga参与者订阅彼此的事件时，循环相关性并不总是一个问题，但循环相关性往往被认为是一种不良的设计风格。 偶联风险：所有Saga参与者都必须订阅影响它们的所有事件。 例如，帐户服务必须订阅消费者信用卡可能被扣款或退款的所有事件。 因此，您可能需要将会计服务的内部代码与Order Service实现的订单生命周期代码同步更新。 编排模式开发人员定义了saga的编排类，所有服务都在该类中进行协调。 saga可编程控制器使用命令/异步响应方式与saga的参与者服务进行通信。
流程：
saga component将验证消费者命令发送到消费者服务。 Consumer Service回复ConsumerVerified消息。 Saga构成器向Kitchen Service发送CreateTicket命令。 Kitchen Service回复TicketCreated消息。 saga component将授权卡消息发送到会计服务。 会计服务使用CardAuthorized消息回复。 Saga可编程控制器向Kitchen Service发送ApproveTicket命令。 Saga可编程控制器向Order Service发送ApproveOrder命令。
将saga组织模式视为状态机是对saga组织器进行建模的好方法。 状态机由一组状态和事件组成
触发的状态之间的转换组成。每个转换都可以有一个动作，对Saga来说动作就是对某个参与方的调用。状态之间的转换由Saga参与方执行的本地事务完成触发。当前状态和本地事务的特定结果决定了状态转换以及执行的动作(如果有的话)。对状态机也有有效的测试策略。因此，使用状态机模型可以更轻松地设计、实现和测试Saga。状态机的初始操作是向Consumer Service发送VerifyConsumer命令。来自Consumer Service的响应触发下一个状态转换。如果Consumer被成功验证，saga将创建ticket并转换到creatingticket状态。但是，如果Consumer验证失败，saga将拒绝订单并转换到rejecting order状态。在saga参与者的响应驱动下，状态机经历了许多其他的状态转换，直到它达到一个最终状态，即订单批准或订单拒绝。
编排式Saga的好处和弊端
好处：
更简单的依赖关系：编排的一个好处是它不会引人循环依赖关系。Saga编排器调用Saga参与方，但参与方不会调用编排器。因此，编排器依赖于参与方，但反之则不然，因此没有循环依赖。较少的耦合：每个服务实现供编排器调用的API，因此它不需要知道Saga参与方发布的事件。改善关注点隔离，简化业务逻辑：Saga的协调逻辑本地化在Saga编排器中。领域对象更简单，并且不需要了解它们参与的Saga。业务更加简单。弊端：
在编排器中存在集中过多业务逻辑的风险。这会导致这样的架构设计：智能编排器告诉哑服务要做什么操作。幸运的是，你可以通过设计只负责排序的编排器来避免此问题，并且不包含任何其他业务逻辑。 隔离问题ACID事务的隔离属性可确保同时执行多个事务的结果与顺序执行它们的结果相同。数据库为每个ACID事务提供了具有对数据的独占访问权的错觉。隔离使得编写并发执行的业务逻辑变得更加容易。
使用Saga的挑战在于它们缺乏ACID事务的隔离属性。这是因为一旦该事务提交，每个Saga的本地事务所做的更新都会立即被其他 Sagas看到。此行为可能导致两个问题。首先，其他Saga可以在执行时更改该Saga所访问的数据。其他Saga可以在Saga完成更新之前读取其数据，因此可能会暴露不一致的数据。
所以可以理解为saga只满足ACID中的ACD。下面简单介绍一下ACID
A atomicity 原子性 一个事务要么全部提交成功，要么全部失败回滚，不能只执行其中的一部分操作，这就是事务的原子性C consistency 一致性 事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。I isolation 隔离性 在并发环境中，并发的事务时相互隔离的，一个事务的执行不能不被其他事务干扰。不同的事务并发操作相同的数据时，每个事务都有各自完成的数据空间，即一个事务内部的操作及使用的数据对其他并发事务时隔离的，并发执行的各个事务之间不能相互干扰。D durability 持久性 一旦事务提交，那么它对数据库中的对应数据的状态的变更就会永久保存到数据库中。 缺乏隔离性导致的问题 丢失更新：一个Saga没有读取更新，而是直接覆盖了另一个Saga所做的更改。脏读：一个事务或一个Saga读取了尚未完成的Saga所做的更新。模糊或不可重复读：一个Saga的两个不同步骤读取相同的数据却获得了不同的结果，因为另一个Saga已经进行了更新。 saga结构
如图所示共有3种模型
使用语义锁对策时，Saga的可补偿性事务会在其创建或更新的任何记录中设置标志。该标志表示该记录未提交且可能发生更改。该标志可以是阻止其他事务访问记录的锁，也可以是指示其他事务应该谨慎地处理该记录的一个警告。这个标志会被一个可重复的事务清除，这表示Saga成功完成；或通过补偿事务清除，这表示Saga发生了回滚。
对策2：交换式更新一个简单的对策是将更新操作设计为可交换的。如果可以按任何顺序执行，则操作是可交换的。这种对策很有用，因为它可以避免更新的丢失。例如，扣款动作，-100元，回滚动作+100元。
对策3：悲观视图处理缺乏隔离性的另一种方法是悲观视图。它重新排序Saga的步骤，以最大限度地降低由于脏读而导致的业务风险。例如，考虑先前用于描述脏读异常的场景。在这种情况下，Create Order Saga执行了可用信用额度的脏读，并创建了超过消费者信用额度的订单。为了降低发生这种情况的风险，此对策将重新排序 Cancel Order Saga。
Order Service：将Order状态更改为已取消。
Delivery Service：取消送货。
Customer Service：增加可用信用额度。
在这个重新排序的Saga版本中，在可重复性事务中增加了可用的信用额度，消除了脏读的可能性。
重读值对策可防止丢失更新。使用此计数器的Saga在更新之前重新读取记录，验证它是否未更改，然后更新记录。如果记录已更改，则Saga将中止并可能重新启动。此对策是乐观脱机锁模式的一种形式。
Create Order Saga可以使用此对策来处理Order在批准过程中被取消的情况。批准Order的事务验证Order是否保持不变，因为它是在Saga早期创建的。如果不变，事务将批准 Order。但是，如果Order已被取消，则事务将中止该Saga，从而触发其补偿事务执行。
版本文件对策之所以如此命名，是因为它记录了对数据执行的操作，以便可以对它们进行重新排序。这是将不可交换操作转换为可交换操作的一种方法。要了解此对策的工作原理，请考虑 Create Order Saga与 Cancel Order Saga同时执行的场景。除非Saga使用语义锁对策，否则 Cancel Order Saga可能会在 Create Order Saga授权信用卡之前取消消费者信用卡的授权。
Accounting Service处理这些无序请求的一种方法是在操作到达时记录操作，然后以正确的顺序执行操作。在这种情况下，它将首先记录 Cancel Authorization请求。然后，当 Accounting Service收到后续的 Authorize Card请求时，它会注意到它已经收到 Cancel Authorization请求并跳过授权信用卡。
最终的对策是基于价值(业务风险)对策。这是一种基于业务风险选择并发机制的策略。使用此对策的应用程序使用每个请求的属性来决定使用Saga和分布式事务。它使用Saga执行低风险请求，可能会应用前几节中描述的对策。但它使用分布式事务来执行高风险请求(例如涉及大量资金)。此对策使应用程序能够动态地对业务风险、可用性和可伸缩性进行权衡。
参考https://blog.csdn.net/ylnlp5602260/article/details/113809953#t25