如何用saga实现分布式事务？

本文主要是介绍如何用saga实现分布式事务？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

SAGA事务介绍

SAGA事务模式的历史十分悠久，比分布式事务的概念提出还要更早。SAGA的意思是“长篇故事、长篇记叙、一长串事件”，它起源于1987年普林斯顿大学的赫克托 · 加西亚 · 莫利纳（Hector Garcia Molina）和肯尼斯 · 麦克米伦（Kenneth Salem）在ACM发表的一篇论文《SAGAS》。

文中提出了一种如何提升“长时间事务”（Long Lived Transaction）运作效率的方法，大致思路是把一个大事务分解为可以交错运行的一系列子事务的集合。原本提出SAGA的目的，是为了避免大事务长时间锁定数据库的资源，后来才逐渐发展成将一个分布式环境中的大事务，分解为一系列本地事务的设计模式。

SAGA由两部分操作组成。

一部分是把大事务拆分成若干个小事务，将整个分布式事务T分解为n个子事务，我们命名为T1，T2，…，Ti，…，Tn。每个子事务都应该、或者能被看作是原子行为。如果分布式事务T能够正常提交，那么它对数据的影响（最终一致性）就应该与连续按顺序成功提交子事务Ti等价。
另一部分是为每一个子事务设计对应的补偿动作，我们命名为C1，C2，…，Ci，…，Cn。

Ti与Ci必须满足以下条件：

Ti与Ci都具备幂等性；
Ti与Ci满足交换律（Commutative），即不管是先执行Ti还是先执行Ci，效果都是一样的；
Ci必须能成功提交，即不考虑Ci本身提交失败被回滚的情况，如果出现就必须持续重试直至成功，或者要人工介入。

如果T1到Tn均成功提交，那么事务就可以顺利完成。否则，我们就要采取以下两种策略：

正向恢复（Forward Recovery）： 其实就是重试。如果Ti事务提交失败，则一直对Ti进行重试，直至成功为止（最大努力交付）。这种恢复方式不需要补偿，适用于事务最终都要成功的场景，比如在别人的银行账号中扣了款，就一定要给别人发货。正向恢复的执行模式为：T1，T2，…，Ti（失败），Ti（重试）…，Ti+1，…，Tn。
反向恢复（Backward Recovery）： 如果Ti事务提交失败，则一直执行Ci对Ti进行补偿，直至成功为止（最大努力交付）。这里要求Ci必须（在持续重试后）执行成功。反向恢复的执行模式为：T1，T2，…，Ti（失败），Ci（补偿），…，C2，C1。

saga的实现

有两种常见的 Saga 实现方法，即协调和编排。每个方法都有自己的一组挑战和技术来协调工作流。

基于编排的实现

假设用户下单场景，此操作必须验证消费者是否可以下订单，验证订单详细信息，授权消费者的信用卡，并在数据库中创建订单。在单体应用程序中实现此操作相对简单。验证订单所需的所有数据都可以轻松获取。而且可以使用 ACID 事务来确保数据一致性。

相比之下，在微服务架构中实现相同的操作要复杂得多。如图所示，所需的数据分散在多个服务中。createOrder() 操作访问多个服务中的数据。它从 Consumer Service 读取数据，并在 Order Service、Kitchen Service 和 Accounting Service 中更新数据。

基于编排的saga：实现sagas的一种方法是使用编排。当使用编排时，没有中央协调员告诉saga参与者该做什么。相反，sagas参与者订阅彼此的事件并做出相应的响应。

通过这个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无法授权消费者信用卡时的事件流。

事件顺序如下：

Order服务在APPROVAL_PENDING状态下创建一个Order并发布OrderCreated事件。
Consumer服务消费OrderCreated事件，验证消费者是否可以下订单，并发布ConsumerVerified事件。
Kitchen服务消费OrderCreated事件，验证订单，在CREATE_PENDING状态下创建故障单，并发布TicketCreated事件。
Accounting服务消费OrderCreated事件并创建一个处于PENDING状态的Credit CardAuthorization。
Accounting服务消费TicketCreated和ConsumerVerified事件，向消费者的信用卡收费，并发布信用卡授权失败事件。
Kitchen服务使用信用卡授权失败事件并将故障单的状态更改为REJECTED。
订单服务消费信用卡授权失败事件，并将订单状态更改为已拒绝。

SEATA基于状态机引擎的 Saga 实现：

目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：

通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚

注意: 异常发生时是否进行补偿也可由用户自定义决定

可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能

示例状态图:

基于控制的实现

控制是实现sagas的另一种方式。使用业务流程时，您可以定义一个控制类，其唯一的职责是告诉saga参与者该做什么。saga控制使用命令/异步回复样式交互与参与者进行通信。我们通过上面下单的例子看下具体步骤：

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参与者执行的本地事务的完成触发。当前状态和本地事务的特定结果决定了状态转换以及执行的操作（如果有的话）。对状态机也有有效的测试策略。因此，使用状态机模型可以更轻松地设计、实施和测试。

图显示了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与TCC对比

比如一个业务是发送邮件，在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则很简单。
没有预留动作就意味着不必担心资源释放的问题，异常处理起来也更简单

所以你能发现，与TCC相比，SAGA不需要为资源设计冻结状态和撤销冻结的操作，补偿操作往往要比冻结操作容易实现得多。

举个例子。账户转账场景，从银行划转货款到Fenix's Bookstore系统中，这步是经由用户支付操作来促使银行提供服务；如果后续业务操作失败，尽管我们无法要求银行撤销掉之前的用户转账操作，但是作为补偿措施，我们让Fenix's Bookstore系统将货款转回到用户账上，却是完全可行的。

SAGA必须保证所有子事务都能够提交或者补偿，但SAGA系统本身也有可能会崩溃，所以它必须设计成与数据库类似的日志机制（被称为SAGA Log），以保证系统恢复后可以追踪到子事务的执行情况，比如执行都到哪一步或者补偿到哪一步了。

另外你还要注意，尽管补偿操作通常比冻结/撤销更容易实现，但要保证正向、反向恢复过程能严谨地进行，也需要你花费不少的工夫。比如，你可能需要通过服务编排、可靠事件队列等方式来完成。所以，SAGA事务通常也不会直接靠裸编码来实现，一般也是在事务中间件的基础上完成。