共计 7203 个字符，预计需要花费 19 分钟才能阅读完成。
1 Saga 相干概念
1987 年普林斯顿大学的 Hector Garcia-Molina 和 Kenneth Salem 发表了一篇 Paper Sagas，讲述的是如何解决 long lived transaction（长活事务）。Saga 是一个长活事务可被分解成能够交织运行的子事务汇合。其中每个子事务都是一个放弃数据库一致性的实在事务。
论文地址：sagas
1.1 Saga 的组成
每个 Saga 由一系列 sub-transaction Ti 组成
每个 Ti 都有对应的弥补动作 Ci，弥补动作用于撤销 Ti 造成的后果
能够看到，和 TCC 相比，Saga 没有“预留”动作，它的 Ti 就是间接提交到库。
Saga 的执行程序有两种：
T1, T2, T3, …, Tn
T1, T2, …, Tj, Cj,…, C2, C1，其中 0 < j < n
Saga 定义了两种复原策略：
backward recovery，向后复原，弥补所有已实现的事务，如果任一子事务失败。即下面提到的第二种执行程序，其中 j 是产生谬误的 sub-transaction，这种做法的成果是撤销掉之前所有胜利的 sub-transation，使得整个 Saga 的执行后果撤销。
forward recovery，向前复原，重试失败的事务，假如每个子事务最终都会胜利。实用于必须要胜利的场景，执行程序是相似于这样的：T1, T2, …, Tj(失败), Tj(重试),…, Tn，其中 j 是产生谬误的 sub-transaction。该状况下不须要 Ci。
显然，向前复原没有必要提供弥补事务，如果你的业务中，子事务（最终）总会胜利，或弥补事务难以定义或不可能，向前复原更合乎你的需要。
实践上弥补事务永不失败，然而，在分布式世界中，服务器可能会宕机，网络可能会失败，甚至数据中心也可能会停电。在这种状况下咱们能做些什么？最初的伎俩是提供回退措施，比方人工干预。
1.2 Saga 的应用条件
Saga 看起来很有心愿满足咱们的需要。所有长活事务都能够这样做吗？这里有一些限度：
Saga 只容许两个档次的嵌套，顶级的 Saga 和简略子事务
在外层，全原子性不能失去满足。也就是说，sagas 可能会看到其余 sagas 的局部后果
每个子事务应该是独立的原子行为
在咱们的业务场景下，各个业务环境（如：航班预订、租车、酒店预订和付款）是天然独立的行为，而且每个事务都能够用对应服务的数据库保障原子操作。
弥补也有需思考的事项：
弥补事务从语义角度吊销了事务 Ti 的行为，但未必能将数据库返回到执行 Ti 时的状态。（例如，如果事务触发导弹发射，则可能无奈吊销此操作）
但这对咱们的业务来说不是问题。其实难以吊销的行为也有可能被弥补。例如，发送电邮的事务能够通过发送解释问题的另一封电邮来弥补。
对于 ACID 的保障：
Saga 对于 ACID 的保障和 TCC 一样：
原子性（Atomicity）：失常状况下保障。
一致性（Consistency），在某个工夫点，会呈现 A 库和 B 库的数据违反一致性要求的状况，然而最终是统一的。
隔离性（Isolation），在某个工夫点，A 事务可能读到 B 事务局部提交的后果。
持久性（Durability），和本地事务一样，只有 commit 则数据被长久。
Saga 不提供 ACID 保障，因为原子性和隔离性不能失去满足。原论文形容如下：
full atomicity is not provided. That is, sagas may view the partial results of other sagas
通过 saga log，saga 能够保障一致性和持久性。
和 TCC 比照
Saga 相比 TCC 的毛病是短少预留动作，导致弥补动作的实现比拟麻烦：Ti 就是 commit，比方一个业务是发送邮件，在 TCC 模式下，先保留草稿（Try）再发送（Confirm），撤销的话间接删除草稿（Cancel）就行了。而 Saga 则就间接发送邮件了（Ti），如果要撤销则得再发送一份邮件阐明撤销（Ci），实现起来有一些麻烦。
如果把下面的发邮件的例子换成：A 服务在实现 Ti 后立刻发送 Event 到 ESB（企业服务总线，能够认为是一个消息中间件），上游服务监听到这个 Event 做本人的一些工作而后再发送 Event 到 ESB，如果 A 服务执行弥补动作 Ci，那么整个弥补动作的层级就很深。
不过没有预留动作也能够认为是长处：
有些业务很简略，套用 TCC 须要批改原来的业务逻辑，而 Saga 只须要增加一个弥补动作就行了。
TCC 起码通信次数为 2n，而 Saga 为 n（n=sub-transaction 的数量）。
有些第三方服务没有 Try 接口，TCC 模式实现起来就比拟 tricky 了，而 Saga 则很简略。
没有预留动作就意味着不用放心资源开释的问题，异样解决起来也更简略（请比照 Saga 的复原策略和 TCC 的异样解决）。
2 Saga 相干实现
Saga Log
Saga 保障所有的子事务都得以实现或弥补，但 Saga 零碎自身也可能会解体。Saga 解体时可能处于以下几个状态：
Saga 收到事务申请，但尚未开始。因子事务对应的微服务状态未被 Saga 批改，咱们什么也不须要做。
一些子事务曾经实现。重启后，Saga 必须接着上次实现的事务复原。
子事务已开始，但尚未实现。因为近程服务可能已实现事务，也可能事务失败，甚至服务申请超时，saga 只能从新发动之前未确认实现的子事务。这意味着子事务必须幂等。
子事务失败，其弥补事务尚未开始。Saga 必须在重启后执行对应弥补事务。
弥补事务已开始但尚未实现。解决方案与上一个雷同。这意味着弥补事务也必须是幂等的。
所有子事务或弥补事务均已实现，与第一种状况雷同。
为了复原到上述状态，咱们必须追踪子事务及弥补事务的每一步。咱们决定通过事件的形式达到以上要求，并将以下事件保留在名为 saga log 的长久存储中：
Saga started event 保留整个 saga 申请，其中包含多个事务 / 弥补申请
Transaction started event 保留对应事务申请
Transaction ended event 保留对应事务申请及其回复
Transaction aborted event 保留对应事务申请和失败的起因
Transaction compensated event 保留对应弥补申请及其回复
Saga ended event 标记着 saga 事务申请的完结，不须要保留任何内容
66ae7b320e502c13f4a21a08baa61ead
通过将这些事件长久化在 saga log 中，咱们能够将 saga 复原到上述任何状态。
因为 Saga 只须要做事件的长久化，而事件内容以 JSON 的模式存储，Saga log 的实现非常灵活，数据库（SQL 或 NoSQL），长久音讯队列，甚至一般文件能够用作事件存储，当然有些能更快得帮 saga 复原状态。
注意事项
对于服务来说，实现 Saga 有以下这些要求：
Ti 和 Ci 是幂等的。
Ci 必须是可能胜利的，如果无奈胜利则须要人工染指。
Ti – Ci 和 Ci – Ti 的执行后果必须是一样的：sub-transaction 被撤销了。
第一点要求 Ti 和 Ci 是幂等的，举个例子，假如在执行 Ti 的时候超时了，此时咱们是不晓得执行后果的，如果采纳 forward recovery 策略就会再次发送 Ti，那么就有可能呈现 Ti 被执行了两次，所以要求 Ti 幂等。如果采纳 backward recovery 策略就会发送 Ci，而如果 Ci 也超时了，就会尝试再次发送 Ci，那么就有可能呈现 Ci 被执行两次，所以要求 Ci 幂等。
第二点要求 Ci 必须可能胜利，这个很好了解，因为，如果 Ci 不能执行胜利就意味着整个 Saga 无奈齐全撤销，这个是不容许的。但总会呈现一些非凡状况比方 Ci 的代码有 bug、服务长时间解体等，这个时候就须要人工染指了。
第三点乍看起来比拟奇怪，举例说明，还是思考 Ti 执行超时的场景，咱们采纳了 backward recovery，发送一个 Ci，那么就会有三种状况：
Ti 的申请失落了，服务之前没有、之后也不会执行 Ti
Ti 在 Ci 之前执行
Ci 在 Ti 之前执行
对于第 1 种状况，容易解决。对于第 2、3 种状况，则要求 Ti 和 Ci 是可替换的（commutative)，并且其最终后果都是 sub-transaction 被撤销。
3 Saga 协调
协调 saga：saga 的实现蕴含协调 saga 步骤的逻辑。当系统命令启动 saga 时，协调逻辑必须抉择并告知第一个 saga 参与者执行本地事务。一旦该事务实现，saga 的排序协调抉择并调用下一个 saga 参与者。这个过程始终继续到 saga 执行了所有步骤。如果任何本地事务失败，则 saga 必须以相同的程序执行弥补事务。构建一个 saga 的协调逻辑有几种不同的办法：
编排（Choreography）：在 saga 参与者中调配决策和排序。他们次要通过替换事件进行沟通。
管制（Orchestration）：在 saga 管制类中集中 saga 的协调逻辑。一个 saga 控制者向 saga 参与者发送命令音讯，通知他们要执行哪些操作。
3.1 编排（Choreography）
基于编排的 saga：实现 sagas 的一种办法是应用编排。当应用编排时，没有地方协调员通知 saga 参与者该做什么。相同，sagas 参与者订阅彼此的事件并做出相应的响应。
Screen Shot 2018-11-27 at 23.24.17
通过这个 sagas 的门路如下：
Order Service 在 APPROVAL_PENDING 状态下创立一个 Order 并公布 OrderCreated 事件。
Consumer Service 生产 OrderCreated 事件，验证消费者是否能够下订单，并公布 ConsumerVerified 事件。
Kitchen Service 生产 OrderCreated 事件，验证订单，在 CREATE_PENDING 状态下创立故障单，并公布 TicketCreated 事件。
Accounting 服务生产 OrderCreated 事件并创立一个处于 PENDING 状态的 Credit CardAuthorization。
Accounting Service 生产 TicketCreated 和 ConsumerVerified 事件，收取消费者的信用卡，并公布信用卡受权流动。
Kitchen Service 应用 CreditCardAuthorized 事件并更改 AWAITING_ACCEPTANCE 票的状态。
Order Service 收到 CreditCardAuthorized 事件，更改订单状态到 APPROVED，并公布 OrderApproved 事件。
创立订单 saga 还必须解决 saga 参与者回绝订单并公布某种失败事件的场景。例如，消费者信用卡的受权可能会失败。saga 必须执行弥补交易以吊销曾经实现的事件。图中显示了 AccountingService 无奈受权消费者信用卡时的事件流。
Screen Shot 2018-11-27 at 23.54.12
事件程序如下：
Order 服务在 APPROVAL_PENDING 状态下创立一个 Order 并公布 OrderCreated 事件。
Consumer 服务生产 OrderCreated 事件，验证消费者是否能够下订单，并公布 ConsumerVerified 事件。
Kitchen 服务生产 OrderCreated 事件，验证订单，在 CREATE_PENDING 状态下创立故障单，并公布 TicketCreated 事件。
Accounting 服务生产 OrderCreated 事件并创立一个处于 PENDING 状态的 Credit CardAuthorization。
Accounting 服务生产 TicketCreated 和 ConsumerVerified 事件，向消费者的信用卡免费，并公布信用卡受权失败事件。
Kitchen 服务应用信用卡受权失败事件并将故障单的状态更改为 REJECTED。
订单服务生产信用卡受权失败事件，并将订单状态更改为已回绝。
牢靠的基于事件的通信
在施行基于编排的 saga 时，您必须思考一些与服务间通信相干的问题。第一个问题是确保 saga 参与者更新其数据库并将事件作为数据库事务的一部分公布。
您须要思考的第二个问题是确保 saga 参与者必须可能将收到的每个事件映射到本人的数据。
编组的 saga 的益处和毛病
基于编舞的 saga 有几个益处：
简略：服务在创立，更新或删除业务时公布事件对象
松耦合：参与者订阅事件并且彼此之间没有间接的理解。
并且有一些毛病：
更难了解：与业务流程不同，代码中没有一个中央能够定义 saga。相同，编排在服务中调配 saga 的实现。因而，开发人员有时很难了解给定的 saga 是如何工作的。
服务之间的循环依赖关系：saga 参与者订阅彼此的事件，这通常会创立循环依赖关系。例如，如果仔细检查图示，您将看到存在循环依赖关系，例如订单服务、会计服务、订单服务。尽管这不肯定是个问题，但循环依赖性被认为是设计问题。
严密耦合的危险：每个 saga 参与者都须要订阅所有影响他们的事件。例如，会计服务必须订阅导致消费者信用卡被免费或退款的所有事件。因而，存在一种危险，即须要与 Order Service 施行的订单生命周期放弃同步更新。
3.2 管制（Orchestration）
管制是实现 sagas 的另一种形式。应用业务流程时，您能够定义一个管制类，其惟一的职责是通知 saga 参与者该做什么。saga 管制应用命令 / 异步回复款式交互与参与者进行通信。
Screen Shot 2018-11-28 at 00.08.51
Order Service 首先创立一个 Order 和一个创立订单控制器。之后，门路的流程如下：
saga orchestrator 向 Consumer Service 发送 Verify Consumer 命令。
Consumer Service 回复 Consumer Verified 音讯。
saga orchestrator 向 Kitchen Service 发送 Create Ticket 命令。
Kitchen Service 回复 Ticket Created 音讯。
saga 协调器向 Accounting Service 发送受权卡音讯。
Accounting 服务部门应用卡片受权音讯回复。
saga orchestrator 向 Kitchen Service 发送 Approve Ticket 命令。
saga orchestrator 向订单服务发送批准订单命令。
应用状态机建模 SAGA ORCHESTRATORS
建模 saga orchestrator 的好办法是作为状态机。状态机由一组状态和一组由事件触发的状态之间的转换组成。每个 transition 都能够有一个 action，对于一个 saga 来说是一个 saga 参与者的调用。状态之间的转换由 saga 参与者执行的本地事务的实现触发。以后状态和本地事务的特定后果决定了状态转换以及执行的操作（如果有的话）。对状态机也有无效的测试策略。因而，应用状态机模型能够更轻松地设计、施行和测试。
Screen Shot 2018-11-28 at 00.12.58
图显示了 Create Order Saga 的状态机模型。此状态机由多个状态组成，包含以下内容：
Verifying Consumer：初始状态。当处于此状态时，该 saga 正在期待消费者服务部门验证消费者是否能够下订单。
Creating Ticket：该 saga 正在期待对创立票证命令的回复。
Authorizing Card：期待 Accounting 服务受权消费者的信用卡。
OrderApproved：示意 saga 胜利实现的最终状态。
Order Rejected：最终状态表明该订单被其中一方参与者们回绝。
SAGA ORCHESTRATION 和 TRANSACTIONAL MESSAGING
基于业务流程的 saga 的每个步骤都包含更新数据库和公布音讯的服务。例如，Order Service 长久保留 Order 和 Create Order Saga orchestrator，并向第一个 saga 参与者发送音讯。一个 saga 参与者，例如 Kitchen Service，通过更新其数据库并发送回复音讯来解决命令音讯。Order Service 通过更新 saga 协调器的状态并向下一个 saga 参与者发送命令音讯来解决参与者的回复音讯。服务必须应用事务性消息传递，以便自动更新数据库并公布音讯。
让咱们来看看应用 saga 编排的益处和毛病。
基于 ORCHESTRATION 的 SAGAS 的益处和毛病
基于编排的 saga 有几个益处：
更简略的依赖关系：编排的一个益处是它不会引入循环依赖关系。saga orchestrator 调用 saga 参与者，但参与者不会调用 orchestrator。因而，协调器依赖于参与者，但反之亦然，因而没有循环依赖性。
较少的耦合：每个服务都实现了由 orchestrator 调用的 API，因而它不须要晓得 saga 参与者公布的事件。
改善关注点拆散并简化业务逻辑：saga 协调逻辑本地化在 saga 协调器中。域对象更简略，并且不理解它们参加的 saga。例如，当应用编排时，Order 类不晓得任何 saga，因而它具备更简略的状态机模型。在执行创立订单 saga 期间，它间接从 APPROVAL_PENDING 状态转换到 APPROVED 状态。Order 类没有与 saga 的步骤绝对应的任何中间状态。因而，业务更加简略。
业务流程也有一个毛病：
在协调器中集中过多业务逻辑的危险。这导致了一种设计，其中智能协调器通知哑巴服务要做什么操作。侥幸的是，您能够通过设计独立负责排序的协调器来防止此问题，并且不蕴含任何其余业务逻辑。
除了最简略的 saga，我倡议应用编排。为您的 saga 施行协调逻辑只是您须要解决的设计问题之一。
作者：shoukai
链接：https://www.jianshu.com/p/e4b…
起源：简书
著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。
