SAGA

前言 当你在处理异步消息时，每个单独的消息处理程序都是一个单独的handler，每个handler之间互不影响。这时如果一个消息依赖另一个消息的状态呢？ 这时业务逻辑怎么处理？ 借用我们上篇文章的业务场景，如果在Ship项目里需要发送一个ShipOrder Command。这个ShipOrder需要依赖Sales.OrderPlaced和Bill.OrderBilled Command的状态，目前我们的两个单独的Message Handler都没有保持任何的状态字段，所以这时如果我们需要完成这个业务模型，就需要跟踪他们的状态。 什么是Saga 这个就是本篇文章要提的saga，定义在NServiceBus框架里，他的本质是一个消息驱动模型里的 状态机 ，或者也可以理解为一系列消息处理程序用来共享状态的业务模型。我理解在消息队列里如果我们要保证消息一致性通常会自己创建一张Event表，这里saga维持状态的角色有点像我们这里的Event表。 好的，回到正题上，如果我们需要在Shipping Service里发送一个ShipOrder，发送他之前需要确定OrderPlaced和OrderBilled的状态，确保这两个消息都收到以后才能发送ShipOrder。 如何使用Saga 当然，我暂且理解Saga的目的是为了处理在长时间运行的任务里保证数据一致性这样的一个角色。 Saga状态

介绍 在redux中更好的解决异步操作 redux-saga相当于在redux原来的数据流中多了一层,对action进行监听 接收到action时,派发一个任务维护state saga通过Generator方式创建,异步方法同步化 正常redux流程 加入redux-saga之后的流程 使用方式 import { createStore, applyMiddleware } from 'redux' import createSagaMiddleware from 'redux-saga' //引入saga文件 import { rootSaga } from './rootSaga' //使用 redux-saga 模块的 createSagaMiddleware 工厂函数来创建一个 Saga middleware。 //运行 rootSaga 之前，我们必须使用 applyMiddleware 将 middleware 连接至 Store。然后使用 const sagaMiddleware = createSagaMiddleware(); const middlewares = [ sagaMiddleware ]; const store = createStore(rootReducer, applyMiddleware(...middlewares));

本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在 GIAC 全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。 Seata： https://gitee.com/seata/seata 一、自研分布式事务解决数据一致性问题 1.1 分布式事务问题产生原因 1.1.1 数据库的水平拆分 蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。 如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。 1.1.2 业务服务化拆分 在业务发展初期，“一块大饼”的单业务系统架构，能满足基本的业务需求。但是随着业务的快速发展，系统的访问量和业务复杂程度都在快速增长，单系统架构逐渐成为业务发展瓶颈，解决业务系统的高耦合、可伸缩问题的需求越来越强烈。 如下图所示，蚂蚁金服按照面向服务（SOA）的架构的设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。

微服务兴起的这几年涌现出不少分布式事务框架，比如ByteTCC、TCC-transaction、EasyTransaction以及最近很火爆的Seata。最近刚看了Seata的源码（v0.5.2），借机记录一下自己对分布式事务的一些理解。（3年前这类框架还没成熟，因项目需要自己也写过一个柔性事务框架）。 本文分五部分，首先明确分布式事务概念的演变，然后简单说下为什么大家不用XA，第三部分阐述两阶段提交的“提升”，第四部分介绍Seata的架构的亮点与问题，第五部分谈下分布式事务的取舍。 限于篇幅一些网上可搜索的细节本文不展开阐述（例如XA、Saga、TCC、Seata等原理的的详细介绍）。 一、分布式事务的泛化 提起分布式事务，最早指涉及的是多个资源的数据库事务问题。 wiki对分布式事务的定义：A distributed transaction is a database transaction in which two or more network hosts are involved. 不过事务一词含义随着SOA架构逐渐扩大，根据上下文不同，可分为两类： System transaction； Business transaction。 前者多指数据库事务，后者则多对应一个业务交易。 与此同时，分布式事务的含义也在泛化，尤其SOA、微服务概念流行起来后，多指的是一个业务场景

转载本文需注明出处：EAWorld，违者必究。 针对分布式架构下的数据一致性，大家也许会问这样的问题：跨系统间分布式事务如何解决？系统内多个服务的分布式事务如何解决？一个服务内多个数据源/数据库的分布式事务如何解决？……这些问题大家是很容易理解的，但是由于术语不准确，所以解释起来会有二义性，所以先要统一语言或者术语，也就是统一概念： 域是一个虚拟的分类，几个系统属于某一个域，例如网上银行和手机银行都属于电子渠道领域； 传统的单体应用，指的就是系统，在微服务架构下，单体应用采用前后端分离模式，前端一般使用 Nginx，Ngnix 进程间采用主备模式，系统的后端可以分为多个应用，每个应用有一组对等的应用进程（也称为应用实例）提供服务，每个应用对应一个数据库，实际上在分库的情况下，有可能一个应用对应多个数据库。复杂一点的是网关，网关由一组对等的网关实例组成，如果多个系统共享一个网关，网关和系统就是1对多的关系，也可以一个系统独享一个网关，就是一对一情况，下图是一个概念的示例，使用的是系统独享网关模式。 这里，我们看看经常问的一些问题：跨系统间分布式事务、系统内多个服务的分布式事务、一个服务内多个数据源/数据库的分布式事务，这些问题完全是从技术的角度做归纳，用上述概念应该改为：系统间的数据一致性、系统内应用间的数据一致性、应用内部对应多数据库的数据一致性

Jimmy Boagard describes a McDonalds fast food chain here comparing it to a scatter gather pattern. Workflow image stolen from above article: Initial Implementation Thoughts: To have a common interface for all of the types of FoodOrdered events that all of the food stations would get and then each food station would be able to consume/create its respective item and publish a common done event. Ex: fries and burger station gets a message regarding an order of Fries, The fries station consumes the order announces an ItemDoneEvent that the saga is listening for. Initial Concerns: Since the Saga

一、简介 与分布式事务TCC一样，目的都是为了在各个服务中正常使用事务。和TCC相比，Saga没有“预留”动作，操作都是直接提交到库。其中： 每个Saga由一系列sub-transaction Ti 组成 每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果 既然Saga的操作都是直接提交到库中，那么当后续的服务操作失败时，我们需要一种方法将已被改变的值更改为之前的状态。 为此Saga定义了两种恢复策略： backward recovery：向后恢复，补偿所有已完成的事务，如果任一子事务失败，则撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。 forward recovery：向前恢复，重试失败的事务，假设每个子事务最终都会成功。适用于必须要成功的场景，此处不需要补偿事务。 显然，向前恢复没有必要提供补偿事务，如果你的业务中，子事务（最终）总会成功，或补偿事务难以定义或不可能，向前恢复更符合你的需求。 注意事项： 对于服务来说，实现Saga有以下这些要求： Ti和Ci是幂等的。假设在执行Ti的时候超时了，如果采用重传策略则会再次发送Ti，那么就有可能出现Ti被执行了两次，所以要求Ti幂等。而如果Ci也超时了，就会尝试再次发送Ci，那么就有可能出现Ci被执行两次，所以要求Ci幂等。 Ci必须是能够成功的，如果无法成功则需要人工介入

1.引言 Microservices(微服务) 是新软件项目中所青睐的架构设计。随着从单一系统到分布式系统的演化不仅发生在应用程序空间中，而且发生在数据存储中，管理数据成为最困难的挑战之一，然而，要从这种类型的方法中获得最大的收益，需要克服前面的几个需求。本文研究了将数据作为服务实现的一些考虑事项。 在遵循微服务设计指南时，我们找到一些对数据处理的参考。其中一些常见的方向包括: 每个服务的使用各自的私有数据库实现松散耦合。 拥抱最终一致性。 为最终一致性事务实现 saga pattern 。 使用 Command Query Responsibility Segregation (CQRS)和API组合。 考虑到这一点，当将松耦合作为体系架构中的一个基本部分时，共享数据库现在就变成了一个反模式，使得事务和查询变得更加困难。每个服务使用数据存储都需要封装数据，而与体系架构的其他域的交互应该只发生在API级别，这鼓励我们隐藏数据实现细节。因此，使用诸如 Spring Boot 这样的轻量级框架只是微服务之旅的第一步。 2.查询的挑战 因为每个服务都有数据存储，所以我们需要使其可供其他服务使用，从而成为该域的入口点。由于所有数据调用都发生在服务级别，并且根据它们的域，当需要组合数据视图时，传统的 table join（表连接） 不再是我们在共享数据库实现中使用的方案。此外

I'm trying to understand sagas , and meanwhile I have a specific way of thinking of them - but I am not sure whether I got the idea right. Hence I'd like to elaborate and have others tell me whether it's right or wrong. In my understanding, sagas are a solution to the question of how to model long-running processes . Long-running means: Involving multiple commands, multiple events and possibly multiple aggregates. The process is not modeled inside one of the participating aggregates to avoid dependencies between them. Basically, a saga is nothing more but a command / event handler that reacts