事务回滚

@Transactional注解 一.事物传播行为介绍: @Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下) 　　@Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务 　　@Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务 　　@Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行,否则抛出异常 　　@Transactional(propagation=Propagation.NEVER) ：必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反) 　　@Transactional(propagation=Propagation.SUPPORTS) ：如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务. 二.事物超时设置: @Transactional(timeout=30) /

假设有如下的业务流程，用户1给用户2转账100元： 转账服务需要执行如下操作： 第1步. 在数据库连接1上执行：update 用户表 set （用户1的余额） = （用户1的余额）- 100； 第2步. 在数据库连接2上执行：update 用户表 set （用户2的余额） = （用户2的余额）+ 100； 可能的问题： 1：第1步操作过程中，数据库1挂了，转账服务无法得知对用户1的扣款操作是否成功； 2：第1步操作成功，第2步操作失败，转账服务回滚第1步的操作时，数据库1挂了； 3：第1步操作成功，第2步操作过程中，数据库2挂了，转账服务无法得知是否成功给用户2加了钱； 基于上面的问题，产生了如下的数据库设计： 转账流程变成了如下步骤： 第1步： 转账服务生成一个事务号，全局唯一； 第2步：转账服务在数据库1上执行事务： 开始事务： update 用户表 set （用户1的余额） = （用户1的余额）- 100； insert 事务表 （事务号，成功） 结束事务： 第3步：转账服务在数据库2上执行事务： 开始事务： update 用户表 set （用户2的余额） = （用户2的余额）+ 100； insert 事务表 （事务号，成功） 结束事务： 这样做的好处 当操作用户1的账户失败时，转账服务可以通过再次查询数据库1的事务表来判断操作是否成功； 当操作用户2的账户失败时

聊一个数据库脚本的版本工具 Liquibase，官网在这里 ，初次看到，挺神奇的，数据库脚本也可以有版本管理，同类型的工具还有 flyway 。 开发过程经常会有表结构和变更，让运维来维护的话，通常会有很大的沟通成本，有时在开发方案有问题的时候，提测失败整个项目需要回滚，代码回滚起来是很容易的，通常有备份，但数据库的话就要人工来逐行分析并写出回滚语句，Liquibase 这时候就有用了。 Liquibase 适用场景感觉不多，所以可能有人没听过它的名头； 首先这种自动执行的家伙肯定是不适合于生产环境的，然后在数据量大的时候是不可能用数据库自带的 alter 语句的，一般都是手动创建另一张表，然后用 sql 语句将数据批量复制过去，再者使用容器化也比它好，个人觉得它一般用于开发和测试环境，比较厉害的一个功能是可以比较两个库的差异然后生成补丁包，上线时可以这么玩。 这篇文章说得不错，我是在这篇基本上写的 核心概念 比奇文学网 https://www.biqi.org/ 首先它是用于管理数据库版本的，所以就会有这些概念：版本号，管理的数据，差异比较，版本回滚 它的版本号由开发人员来维护，使用 author + id 管理的数据最小单元为 changeSet ，这个 changeSet 看官网说是可以用 xml,yaml,json,sql 来编写 提交数据，比较差异，版本回滚

Spring transaction 什么是事务 A用户向B用户转帐100，第一步要从A帐户扣出100，第二步要将B帐户加上100。其中无论是第一步失败，还是第二步失败。都应该将A、B帐户的余额保持和转帐操作之前一致。 事务就是一系列相关联操作的集合，一个事务可以是多个步骤组成，如果一个步骤失败，那么整个流程都应该回滚到初始状态。 事务的四个特性 原子性（Atomicity） 一个事务是一个整体，无论有多少个步骤组成，要么所有步骤都成功，要么所有步骤都失败。 一致性（Consistency） 一个事务完成（无论是成功还是失败），所有的业务都应该处于一致的状态，不应该部分步骤成功，部分步骤失败，显示中的数据一致性不会被破坏。 隔离性（Isolation） 多个事务处理相同的数据的时候，事务间应该是相互隔离的，防止数据损坏。 持久性（Durability） 一旦事务完成，无论系统发生什么异常，结果都不应该受到影响，通常事务的结果被写入到数据库中。 Spring处理事务的核心接口 Spring涉及到事务管理的核心接口相互关系如下 Spring并没有直接提供事务管理的实现，而是提供了一个接口PlatformTransactionManager。具体的实现依赖项目中所使用的持久化接口。 PlatformTransactionManager 定义了所有的具体实现类必须要有的方法

Fescar原理 1、概述 fescar刚推出不久，没几天。看了github的Issues，有人问：可以直接商用吗？ 作者的回复： image 我们也看一下fescard的历史： 阿里是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。 2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。 2016 年，TXC 经过产品化改造，以 GTS（Global Transaction Service） 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。 2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。 TXC/GTS/Fescar 一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。 阿里出品的中间件有一种精神是值得赞扬的，就是出品的任何中间件都是业务中已经使用多年的产品。都是经过锤炼的产品，开源的话，去除和内部业务耦合的代码，开源出来。至少有一点，底层的代码是经历过双11这种高并发请求量打磨过的代码

事务传播行为 “事务传播行为”描述的是：当一个事务方法被另一个方法调用时，该事务方法如何进行？ 是创建新事务？丢弃事务？还是加入到已存在的事务呢？ 针对这些情况，Spring框架定义了七种事务传播行为，开发人员可以根据实际的业务场景来选择合适的传播行为。 七种事务传播行为 Spring将其定义在一个枚举类 Propagation 中，分别如下： REQUIRED 如果当前没有开启事务，就开启一个新事务，如果当前开启了事务，就加入该事务，默认行为。 SUPPORTS 如果当前开启了事务，就加入该事务，否则非事务执行。 MANDATORY 如果当前开启了事务，就加入该事务，否则抛出异常。说白了，强制事务，不允许非事务执行。 REQUIRES_NEW 始终创建新事务，如果当前开启了事务，则将当前事务挂起。 NOT_SUPPORTED 强制以非事务执行，如果当前开启了事务就将当前事务挂起再执行。 NEVER 非事务执行，如果当前开启了事务则抛出异常。 NESTED 如果当前开启了事务，则在嵌套事务内执行，否则开启一个事务执行。 特别提醒 Spring的事务是基于代理类通过AOP来实现的，如果希望事务传播生效，那么必须通过Spring生成的代理类来调用方法，Spring在增强代理类中判断是否要开启事务，在同一个类中直接调用自身方法Spring是无法帮我们开启事务的！ 如下例子

性能调优系列前序文章索引： 程序员必须掌握的性能调优 ：老兵哥结合个人经历解释了程序员往架构师方向发展时为什么要跨越性能调优这一关，以及介绍了从 X、Y、Z 三个维度优化性能的思路。 从 X 维度优化系统的性能 ：老兵哥分享了从 X 维度优化系统性能的思路，包括让客户端分计算存储任务、优化交互设计等，主要是作为引子拓宽我们性能调优的思路。 应用容器 Tomcat 性能调优 ：Y 维度就是从业务 HTTP 请求的横向处理流程来看，HTTP 请求会穿越网络、计算机、应用容器（Tomcat）、Spring、ORM（Hibernate）、数据库等节点，在这个流程中每个节点都有许多可以可优化的地方，此文主要介绍通过优化应用容器（Tomcat）来优化系统性能的方法。 程序员在转型架构师的过程中需要建立流程化、结构化、系统化的思维方式，而性能调优是非常难得的契机，它既给了我们压力，也给了我们动力，跨越它就是突破自己的过程。建议在阅读本文内容前，先参考下面这个系列的文章了解 Web 应用是怎样处理 HTTP 请求的： 图解 Spring：HTTP 请求的处理流程与机制【1】 图解 Spring：HTTP 请求的处理流程与机制【2】 图解 Spring：HTTP 请求的处理流程与机制【3】 图解 Spring：HTTP 请求的处理流程与机制【4】 图解 Spring：HTTP 请求的处理流程与机制

在这里主要介绍Spring对事务管理的一些理论知识，实战方面参考上一篇博文: http://www.cnblogs.com/longshiyVip/p/5061547.html 1. 事务简介： 事务管理是企业级应用程序开发中必不可少的技术，用来确保数据的完整性和一致性 事务就是一系列的动作，它们被当作一个单独的工作单元。这些动作要么全部完成，要么全部不起作用 2. 事务的四个关键属性(ACID) ① 原子性(atomicity):事务是一个原子操作，有一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用 ② 一致性(consistency):一旦所有事务动作完成，事务就被提交。数据和资源就处于一种满足业务规则的一致性状态中 ③ 隔离性(isolation):可能有许多事务会同时处理相同的数据，因此每个事物都应该与其他事务隔离开来，防止数据损坏 ④ 持久性(durability):一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响。通常情况下，事务的结果被写到持久化存储器中 3. Spring中的事务管理 作为企业级应用程序框架，Spring在不同的事务管理API之上定义了一个抽象层。而应用程序开发人员不必了解底层的事务管理API，就可以使用Spring的事务管理机制。 Spring既支持编程式事务管理(也称编码式事务)，也支持声明式的事务管理

spring通过ioc创建bean的三种方式 一、使用自动装配创建bean Spring主要从两个角度来实现自动化装配：①组件扫描；②自动装配。组件扫描指的是Spring会自动扫描指定包及其子包下的所有bean，并将其放入spring容器中进行管理，而自动装配则是指对于有相互依赖关系的bean，Spring会将其自动装配到目标bean中，如将repository层的bean自动装配到service层中。 自动装配的方式创建bean主要是使用一个被专门用来当做配置的接口（或类）来实现的。配置接口上主要使用两个注解：@Configuration和@ComponentScan。@Configuration来标注该接口是用于定义配置的，而@ComponentScan则是用于指定扫描的bean的文件夹的，默认情况下Spring会扫描该配置接口所在包及其子包下的所有bean。 这样Spring就可以自动创建一个SgtPeppers的实例，并且将其放到Spring容器中进行管理，另外我们也可以使用@Named注解来创建一个bean。 上面只是讲了如何创建一个bean，而自动装配还有另一方面的概念：依赖注入。其是指Spring会将一个bean所依赖的bean自动装配进来。依赖注入是通过@Autowired或@Resource来实现的，当一个bean需要另一个bean作为其属性的时候

特点 原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability) 一、事务的目的 1、可靠性和并发处理 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 二、实现事务功能的三个技术 1、日志文件(redo log 和 undo log) 2、锁技术 3、MVCC 1.1 redo log 与 undo log介绍 1.1.1redo log 什么是redo log ? redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。 当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi） start transaction; select