Saga与工作流引擎比较

  Sagas并不为人所熟知,但为使用工作流程提供了灵感。
将传奇与工作流进行比较有助于澄清经常被忽视的工作流的更微妙和隐藏的特征。

 

Saga的失败补偿模式

  Saga于1987年首次应用于海克特Garcaa-Molrna和肯尼思·萨利姆的研究论文。它是作为长时间分布式事务的概念替代方案而引入的。

  saga是将较大的事务,它被分成一组较小的事务。这减少了必须在数据库资源上保留锁的时间,因此可以避免瓶颈。每个较小的交易都可以通过补偿行动撤消。

  如果中途必须中止大型事务,则必须对已经完成的所有较小的交易进行补偿回退。因此,本质上一个Saga是一种失败模式。

  解释Saga的最简单的例子是预订商务旅行。这个过程需要预订酒店、航班、汽车。如果在预订过程中中止,则需要取消之前的预定。

该过程中的每个步骤都具有相应的取消操作,在失败时以相反的顺序触发。

 

Saga与工作流相关点

  一个工作流程,也称为业务流程,在这个意义上,它也定义了一个更大的任务,作为一组单独的活动类似。通常可以用图形方式指定必须使用箭头或过渡执行活动的顺序。因此,工作流程的重点是执行。工作流指定执行流。箭头或转换用于指示必须按顺序执行活动。并行网关等特殊构造允许并行执行活动。

Saga在CQRS的背景下具有不同的含义。在CQRS架构中,saga从实现的角度来指工作流或流程管理器,主要侧重解决微服务下的分布式事务问题。

  但是事务和交易的英文都是Transaction,事务是一个技术名称,而交易时一个业务名称,对应工作流中一个业务流程,一个业务流程完成一个交易,一个交易需要一个业务流程去完整没有错误地完成。

  通过工作流程系统中的活动进行补偿,如果工作流被取消或中止,则可以补偿已执行的活动。

  电子邮件作为工作流中的活动发送;工作流中止时发送的补偿电子邮件。
  当活动中有上传文件时,整个工作流失败时,可以将其删除。

  这种事后补偿式方式在日常生活很常见,某上市公司刚刚发布过去一个季度的业绩报告,但是隔了两天就发布业绩修正报告,这其实也是一种技术上的事务补偿。

Saga和工作流区别

  工作流是反映人们的需求意图,工作流引擎驱动各种人工任务和服务任务完成一个流程,当意图被业务系统执行以后,相应状态被改变,系统抛出相应的事件,Saga是对这些事件进行记录,在一个流程执行过程中发生中断时,能够自动将业务系统中状态进行还原。

#Saga事务#CQRS

BPMN专题