SAGA

分布式事务Saga (一) TCC vs Saga 分布式事务Saga（二）事务管理者SagaTransactionalAspect 分布式事务Saga（三）事务参与方管理SagaParticipantAspect 分布式事务Saga（四）事务恢复SagaRecoveryManager 文章目录 TCC流程 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 saga 正常流程图 saga 异常流程图 结论 项目地址： https://github.com/yangxb2010000/saga 该项目的实现本质上说不是一个严格意义上的Saga实现，更像是一个简化版的TCC事务 先对比一下Saga与TCC的区别 TCC流程 Try 预留资源 （如：库存服务的预占库存，支付服务的冻结部分账户余额） Confirm 如果所有的事务参与者try 操作都执行成功了，就会调用所有事务参与者的confirm操作，确认资源。（如：库存服务的减库存，支付服务的扣减账户余额） Cancel 如果有事务参与者在try阶段执行失败，就调用所有已执行try阶段成功的参与方的cancel方法，释放try阶段占用的资源（如：库存服务的释放预占库存，支付服务的释放冻结的账户余额） ####正常逻辑时序图 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 confirm 直接执行资源操作，（如

Redux-saga Saga相关概念 1987年普林斯顿大学的Hector Garcia-Molina和Kenneth Salem发表了一篇Paper Sagas，讲述的是如何处理long lived transaction（长活事务）。Saga是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务。 redux-saga是一个用于管理redux应用异步操作的中间件 redux-saga通过创建sagas将所有异步操作逻辑收集在一个地方集中处理，可以用来代替redux-thunk中间件。 这意味着应用的逻辑会存在两个地方 (1) reducer负责处理action的stage更新 (2) sagas负责协调那些复杂或者异步的操作 sagas是通过generator函数来创建的 sagas可以被看作是在后台运行的进程。sagas监听发起的action，然后决定基于这个action来做什么 (比如：是发起一个异步请求，还是发起其他的action到store，还是调用其他的sagas 等 ) 在redux-saga的世界里，所有的任务都通过用 yield Effects 来完成 ( effect可以看作是redux-saga的任务单元 ) Effects 都是简单的 javascript对象，包含了要被 saga middleware

简介 redux-saga 是用来管理应用程序副作用的库，可以认为，一个saga就像是应用程序中一个单独的线程，独自负责处理副作用。 redux-saga 是一个Redux中间件，也就意味着这个线程可以通过正常的Redux的Action从主应用启动暂停和取消，它能够访问完整的Redux的State，也可以进行 dispatch redux-saga 使用了 Generator ，让异步流程看起来像是同步代码，有更强大的异步流程控制能力。 Hello Saga 安装： npm install --save redux-saga # 或者 yarn add redux-saga 创建 sagas.js 文件，我们的异步逻辑都会包含在这个文件中： // sagas/index.js export default function* helloSaga() { console.log('Hello Sagas!'); } Redux-Saga是一个中间件，我们需要建立它与Redux Store的联系，在 store/configureStore.js 中对 store 进行配置，注入中间件： // store/configureStore.js import { createStore, applyMiddleware } from 'redux'; import rootReducer

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 转载本文需注明出处：微信公众号EAWorld，违者必究。 引言： 微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，从而被越来越多的开发者和公司推崇运用。但系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出，几乎可以说是无法避免。 分布式事务已经成为微服务落地较大的阻碍，也是较具挑战性的一个技术难题。那么我们在实际开发中需要如何去应对呢？本文将介绍在实际微服务开发中分布式事务的实战。 目录： 1.分布式事务讲解 2.分布式事务解决方案-servicecomb-pack 3.分布式事务实战讲解 1. 分布式事务讲解 1.1事务原理 在讲分布式事务之前，先聊一下事务。简单讲事务是数据库管理系统执行过程中的一个逻辑单元，它能保证要么一组数据库操作全部执行成功，要么全部失败，而做到这些的原理就是事务的ACID四大特性。 A. Atomic原子性的简称，事务作为一个整体来执行，要么全部成功，要么全部失败。 C. Consistency一致性的简称，事务应确保数据从一个一致的状态转变为另一个一致的状态。 I. Isolation隔离性的简称，多个事务并发执行时，一个事务的执行不影响其他事务的执行。

参考： https://blog.csdn.net/sinat_17775997/article/details/103524043 https://www.jianshu.com/p/6f96bdaaea22 redux-saga 中常见的几种模式(翻译)https://www.jianshu.com/p/c3425f9ef6b7 take([...]) 和 race 的比较重要的语境区别是： take([...]) 是等待第一个相匹配的action的到达 race 是等待第一个 racing-effect 的完成 1.概述 Redux-saga是一个用于管理 Redux 应用异步操作的中间件（又称异步action） 本质都是为了解决异步action的问题 Redux Saga可以理解为一个和系统交互的常驻进程，这个线程可以通过正常的Redux Action从主应用程序启动， 暂停 和 取消 ，它能访问完整的Redux state，也可以dispatch Redux Action。 一个 Saga 就像是应用程序中一个单独的线程，它独自负责处理副作用。 其中，Saga可简单定义如下的公式： Saga = Worker + Watcher 2.简单使用 redux-saga本质是一个可以自执行的generator。 在 redux-saga 中，UI 组件自身从来不会触发任务

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> GTS 今年双 11 的成绩 今年 2684 亿的背后，有一个默默支撑，低调到几乎被遗忘的中间件云产品——GTS（全局事务服务，Global Transaction Service），稳稳地通过了自 2014 年诞生以来的第 5 次“大考”。 2019 年 11 月 1 日至 12 日，GTS 日均处理分布式事务数量达 亿级 ，每天峰值 TPS 达 万级 。 这背后最重要意义在于：成绩是在给业务应用的设计和开发带来 0 负担 的前提下得到的。 GTS 带来的价值 随着企业的发展，企业业务架构面临数据、服务的分布化，几乎无可避免地要遇到分布式架构带来的数据一致性问题。 GTS 开创性地把分布式事务问题从业务中剥离出来，作为一个独立的技术切面来单独管理，以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。 GTS 给业务应用带来的价值体现在以下几个方面： 架构复杂度降低：分布式事务这个 切面 的技术问题，全部 收敛 到 GTS 提供的服务来解决。 设计和开发成本减轻：业务逻辑的设计和开发，完全不需要针对是否涉及分布式事务而做任何额外的事情，对业务 0 侵入 。 项目交付、迭代速度加快：归因于上述两点，项目得以很快交付和迭代。GTS 赋予业务应用 快速试错 的能力，在这个商业机会瞬息万变的时代