国家关于网站信息建设管理文件,找人做彩票网站多少钱,网页设计公司员工,网站建站什么目录SAGA事务介绍
SAGA事务模式的历史十分悠久#xff0c;比分布式事务的概念提出还要更早。SAGA的意思是“长篇故事、长篇记叙、一长串事件”#xff0c;它起源于1987年普林斯顿大学的赫克托 加西亚 莫利纳#xff08;Hector Garcia Molina#xff09;和肯尼斯 麦克米伦比分布式事务的概念提出还要更早。SAGA的意思是“长篇故事、长篇记叙、一长串事件”它起源于1987年普林斯顿大学的赫克托 · 加西亚 · 莫利纳Hector Garcia Molina和肯尼斯 · 麦克米伦Kenneth Salem在ACM发表的一篇论文《SAGAS》。
文中提出了一种如何提升“长时间事务”Long Lived Transaction运作效率的方法大致思路是把一个大事务分解为可以交错运行的一系列子事务的集合。原本提出SAGA的目的是为了避免大事务长时间锁定数据库的资源后来才逐渐发展成将一个分布式环境中的大事务分解为一系列本地事务的设计模式。
SAGA由两部分操作组成。 一部分是把大事务拆分成若干个小事务将整个分布式事务T分解为n个子事务我们命名为T1T2…Ti…Tn。每个子事务都应该、或者能被看作是原子行为。如果分布式事务T能够正常提交那么它对数据的影响最终一致性就应该与连续按顺序成功提交子事务Ti等价。 另一部分是为每一个子事务设计对应的补偿动作我们命名为C1C2…Ci…Cn。 Ti与Ci必须满足以下条件 Ti与Ci都具备幂等性 Ti与Ci满足交换律Commutative即不管是先执行Ti还是先执行Ci效果都是一样的 Ci必须能成功提交即不考虑Ci本身提交失败被回滚的情况如果出现就必须持续重试直至成功或者要人工介入。
如果T1到Tn均成功提交那么事务就可以顺利完成。否则我们就要采取以下两种策略 正向恢复Forward Recovery 其实就是重试。如果Ti事务提交失败则一直对Ti进行重试直至成功为止最大努力交付。这种恢复方式不需要补偿适用于事务最终都要成功的场景比如在别人的银行账号中扣了款就一定要给别人发货。正向恢复的执行模式为T1T2…Ti失败Ti重试…Ti1…Tn。 反向恢复Backward Recovery 如果Ti事务提交失败则一直执行Ci对Ti进行补偿直至成功为止最大努力交付。这里要求Ci必须在持续重试后执行成功。反向恢复的执行模式为T1T2…Ti失败Ci补偿…C2C1。
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为nnsub-transaction的数量。 有些第三方服务没有Try接口TCC模式实现起来就比较tricky了而Saga则很简单。 没有预留动作就意味着不必担心资源释放的问题异常处理起来也更简单
所以你能发现与TCC相比SAGA不需要为资源设计冻结状态和撤销冻结的操作补偿操作往往要比冻结操作容易实现得多。
举个例子。账户转账场景从银行划转货款到Fenixs Bookstore系统中这步是经由用户支付操作来促使银行提供服务如果后续业务操作失败尽管我们无法要求银行撤销掉之前的用户转账操作但是作为补偿措施我们让Fenixs Bookstore系统将货款转回到用户账上却是完全可行的。
SAGA必须保证所有子事务都能够提交或者补偿但SAGA系统本身也有可能会崩溃所以它必须设计成与数据库类似的日志机制被称为SAGA Log以保证系统恢复后可以追踪到子事务的执行情况比如执行都到哪一步或者补偿到哪一步了。
另外你还要注意尽管补偿操作通常比冻结/撤销更容易实现但要保证正向、反向恢复过程能严谨地进行也需要你花费不少的工夫。比如你可能需要通过服务编排、可靠事件队列等方式来完成。所以SAGA事务通常也不会直接靠裸编码来实现一般也是在事务中间件的基础上完成。
总结
很多时候我们不需要强调强一性我们基于 BASE 和 Saga 理论去设计更有弹性的系统在分布式架构下获得更好的性能和容错能力。分布式架构没有银弹只有适合特定场景的方案事实上 Seata Saga 是一个具备“服务编排”和“Saga 分布式事务”能力的产品总结下来它的适用场景是 适用于微服务架构下的“长事务”处理 适用于微服务架构下的“服务编排”需求 适用于金融核心系统以上的有大量组合服务的业务系统比如在渠道层、产品层、集成层的系统 适用于业务流程中需要集成遗留系统或外部机构提供的服务的场景这些服务不可变不能对其提出改造要求。
