分布式事务

从事务理论的角度来看，可以把事务分为以下几种类型 扁平事务(Flat Transactions) 带有保存点的扁平事务(Flat Transactions with Savepoints) 链事务(Chained Transactions) 嵌套事务(Nested Transactions) 分布式事务(Distributed Transactions) 扁平事务 是事务类型中最简单的一种，但是在实际生产环境中，这可能是使用最频繁的事务，在扁平事务中，所有操作都处于同一层次，其由BEGIN WORK开始，由COMMIT WORK或ROLLBACK WORK结束，其间的操作是源自的，要么都执行，要么都回滚，因此扁平事务是应用程序称为原子操作的的基本组成模块 下面显示了扁平事务的三种不同结果 给出的扁平事务的三种情况，同时也给出了一个典型的事务处理应用中，每个结果大概占用的百分比。再次提醒，扁平事务虽然简单，但是在实际环境中使用最为频繁，也正因为其简单，使用频繁，故每个数据库系统都实现了对扁平事务的支持 扁平事务的主要限制是不能提交或者回滚事务的某一部分，或分几个步骤提交。下面给出一个扁平事务不足以支持的例子。例如用户在旅行网站上进行自己的旅行度假计划，用户设想从杭州到意大利的佛罗伦萨，这两个城市没有直达的班机，需要用户预订并转呈航班，需要或者搭火车等待。用户预订旅行度假的事务为

一、什么是Cap CAP 是一个基于 .NET Standard 的 C# 库，它是一种处理分布式事务的解决方案，同样具有 EventBus 的功能，它具有轻量级、易使用、高性能等特点。 在我们构建 SOA 或者 微服务系统的过程中，我们通常需要使用事件来对各个服务进行集成，在这过程中简单的使用消息队列并不能保证数据的最终一致性， CAP 采用的是和当前数据库集成的本地消息表的方案来解决在分布式系统互相调用的各个环节可能出现的异常，它能够保证任何情况下事件消息都是不会丢失的。 你同样可以把 CAP 当做 EventBus 来使用，CAP提供了一种更加简单的方式来实现事件消息的发布和订阅，在订阅以及发布的过程中，你不需要继承或实现任何接口。 以下是CAP集在ASP.NET Core 微服务架构中的一个示意图： 二、安装 你可以运行以下下命令在你的项目中安装 CAP。 PM> Install-Package DotNetCore.CAP CAP 支持 Kafka、RabbitMQ、AzureServiceBus 等消息队列，你可以按需选择下面的包进行安装： PM> Install-Package DotNetCore.CAP.Kafka PM> Install-Package DotNetCore.CAP.RabbitMQ PM> Install-Package DotNetCore

分布式事务简介 理论不多说，谈起事务，必然就绕不过ACID。然而传统的分布式事务在当下的分布式、微服务结构中中并不太合适，数据在传统的分布式事务中会被锁住，而且还要应对XA协议带来的开销（建立和关闭与资源管理器的连接、预提交、提交和回滚一个本地事务等等）。 与之相对的，是更符合当下业务需求的基于BASE理论的柔性事务。 看看ACIＤ和BASE的区别 Soft State：柔性状态 【ACIＤ(A,I)::原子性，隔离性】与【BASE(S)::柔性状态】：比如说在支付系统中，有一个支付业务系统和积分系统，如果要满足原子性与隔离性，那么逻辑肯定是这样的： 要么是支付成功，加积分，在这期间，积分数据与支付数据是不可访问的。 要么是支付失败，积分不变，在这期间，积分数据与支付数据是不可访问的。 但是在BASE的柔性状态中，允许出现 支付成功，积分不变，并且在支付成功后，其他服务查询我的支付状态时，也会是成功的。在这期间，积分数据与支付数据是可访问的。 加积分，支付失败，在这期间，积分数据与支付数据是可访问的。 这样的情况，柔性事务中，允许数据短暂的不一致，以及非隔离性的操作。 Eventual Consistency：最终一致性 【ACIＤ(A,D)::原子性，持久性】与【BASE(E)最终一致性】：最终一致性指的是系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 知识脑图： 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性，ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用

分布式系统下，分布式数据库遇到的挑战 　　分布式系统下，当访问关系型数据库的i/o占用过高，内存不足，访问过慢的情况下，可以考虑流流行的分库分表的策略，但是这样也会到来很多新的技术挑战。 1.分布式事务 　　当还是单体应用，单体数据库时，完全不需要考虑事务的一致性问题，因为mysql已经帮我们处理事务问题(ACID)，但是这只是针对单体情况下，如果是多个数据库，主从备份，读写分离，那么就会可能造成事务不一致的情况，那么什么事分布式事务，分布式 　　事务又该如何解决呢？ 　　 　　1.有关于事务的概念 　　　　本地事务：本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。 　　　　全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 　　　　两阶段事务：两阶段事务提交采用的是X/OPEN组织所定义的 DTP模型 ，通过抽象出来的 AP , TM , RM 的概念可以保证事务的强一致性。 其中 TM 和 RM 间采用 XA 的协议进行双向通信。 与传统的本地事务相比， 　　　　　　　　　　XA事务增加了prepare阶段，数据库除了被动接受提交指令外，还可以反向通知调用方事务是否可以被提交。 因此 TM 可以收集所有分支事务的prepare结果

闲话 最近简单的学习了一下 springboot，记录下自己的一些学习心得，没有体系，没有深入讲解，基本只涉及到一些概念级，权当随笔记录。。他日翻看时，希望能有所帮助，肯定也有理解不到位之处，还请大家指正 为什么会有 spring 学习一项技术，我们首先需要弄明白，这项技术出现的意义是什么，它能够解决什么场景问题，知其然，必先知其所以然 一般大型的企业级java应用，都会包含很多的内容模块，包括各种接口、逻辑、页面、存储等，它们之间可能存在复杂的依赖关系，如何对他们进行统一的管理和调度是影响开发效率的重要因素 容器化管理我们的应用程序，是上述问题的通用解决方案：应用的开发针对 pojo、bean或者组件，然后交由容器去负责组装调用，实现解耦 在spring之前，java官方推荐的解决方案是 EJB，但是 EJB 是一个非常重型的框架，上手成本很高，对于中小型的企业应用支持并友好 于是民间组织在 EJB 的容器化管理的基础上，创建了 spring，相对来说更轻量级的开发框架，简单对比 EJB 的话，他俩的优缺点： EJB 面向的是组件级容器管理，spring 则是 bean 的管理，更细粒度，对于开发的理解更容易 EJB 和 spring 都支持 ioc 和 aop，但是 spring 封装的功能更强大简单，早期spring只支持xml配置方式，ejb只支持注解方式，随着发展

Spring初探 1. Spring是什么？ Spring 是一个开源的轻量级 Java SE（ Java 标准版本）/Java EE（ Java 企业版本）开发应用框架，其目的是用于简化企业级应用程序开发。在传统应用程序开发中，一个完整的应用是由一组相互协作的对象组成的。所以开发一个应用除了要开发业务逻辑之外，最多的是关注使这些对象协作来完成所需功能的同时，实现低耦合、高内聚。所以，业务逻辑开发是不可避免的。如果有个框架可以帮我们来创建对象及管理这些对象之间的依赖关系，能通过配置方式来创建对象，管理对象之间依赖关系，我们不需要通过工厂和生成器来创建及管理对象之间的依赖关系，这样我们必然会减少许多工作量，加快开发。Spring 框架问世之初主要就是来完成这个功能。 2. Spring技术可以用来干什么？ Spring 框架除了帮我们管理对象及其依赖关系，还提供像通用日志记录、性能统计、安全控制、异常处理等面向切面的能力，可以帮我们管理最头疼的数据库事务，同时，它本身提供了一套简单的 JDBC 访问实现，能与第三方数据库访问框架集成（如 Hibernate、JPA ），与各种 Java EE 技术整合（如 Java Mail、任务调度等等），提供一套自己的 web 层框架 Spring MVC 、而且还能非常简单的与第三方 web 框架集成。从这里我们可以认为 Spring

前言 消息队列 在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在 消息队列 的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（ 请允许我使用一下夸张的修辞手法 ）。 于是在一个寂寞难耐的夜晚， 暖男 我痛定思痛，决定开始写 《吊打面试官》 系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 捞一下 上一期，简单的介绍了一下 消息队列 的基础知识，里面有消息队列的应用场景，以及使用之后可能带来的问题，但是上期没对怎么解决这些问题做回答，因为要控制篇幅嘛（明明是自己觉得MQ写不了多少期，要多怼一期出来！渣男） 咳咳，我们言归正传，没看的朋友去看一下，有助于这期的阅读： 《吊打面试官》系列-消息队列基础 面试开始 一个风度翩翩，穿着格子衬衣的中年男子，拿着一个满是划痕的mac向你走来，看着铮亮的头，心想着肯定是尼玛顶级架构师吧！但是我们看过暖男敖丙的系列，腹有诗书气自华，虚都不虚。 没错小伙子还是我，上次话说一半你就溜了，这次我非得好好的问问你。 好的面试官，因为上次着急，敖丙的系列更新了所以赶回家去看了！ 我信你个鬼，我们开始吧，上次说到了消息队列的消息重复消费

浅谈分布式一致性与CAP/BASE/ACID理论 https://www.cnblogs.com/zhang-qc/p/6783657.html 　　 ##转载请注明 　　CAP理论（98年秋提出，99年正式发表）： C（ Consistency）一致性： 在分布式系统中，数据一致更新，所有数据变动都是同步的； A（ Availability）可用性： 分布式系统中，部分节点故障，系统是否依然可响应客户端请求（对数据更新具备高可用性）； P（ Partition tolerance）分区容错性： 分区是相对于通信的时延要求来讲，指在时延要求内部分节点与其它节点联系不可达，在该情况下系统是否依然可用（可靠性）。该场景下不同于节点宕机情况，可能由于网络交换器故障，使形成不同分区，分区不可达，或者是当前延迟过大，超过了设定的值。 点对点的网络上，复杂的拓扑结构和独立的路由选择可能使连接具有非对称（asymmetric）、非传递的特性，使进程间不可以通信。 由于网络存在延迟和丢包等问题，P性质相对必须满足，所以常在C和A之间进行权衡。CAP理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据

4. 分布式事务解决方案之TCC 4.1. 什么是TCC事务 TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作 ：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。 分支事务失败的情况 ： TCC分为三个阶段 ： Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。 Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即 ：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了