回滚

@Transactional原理 事务是一些sql语句对数据库操作的集合，因此如果在一个Java方法里涉及了对数据库的操作，业务需要的话我们就可以考虑把这些操作作为一个事务。通过在方法上加个@Transactional(....)注解即可。 如： public class Transaction { @Transactional(....) public void doSomething() { ..... } } 对于springboot，加了@Transactional的方法其实是这样执行的： BEGIN TRANSACTION; try{ doSomething(); //执行方法 COMMIT; }catch(Throwable t){ if(t是该回滚的异常) ROLLBACK; else COMMIT; } 知道了注解的原理就好办了，接下来只需了解这个注解的参数即可应付很多业务场景。 控制回滚参数 在@Transactional(rollbackFor = xx.class , noRollbackFor = yy.class)中，使用了控制回滚的参数。rollbackFor = xx.class 表示抛出的异常时xx类及其子类，事务会回滚； noRollbackFor = yy.class表示抛出异常是yy类或其子类，事务不会回滚。 catch到异常怎么办

一、什么是redis事务？ 　　可以一次性执行多条命令，本质上是一组命令的集合。一个事务中的所有命令都会序列化，然后按顺序地串行化执行，而不会被插入其他命令 二、Redis 事务可以做什么？ 　　一个队列中，一些性，顺序性，排他性的执行一系列的命令 三、怎么使用 redis 命令？ 　　1、事务相关的命令： 　　　　（1）DISCARD：取消事务，放弃执行事务块中的所有命令 　　　　（2）EXEC：执行事务块中的命令 　　　　（3）MULTI：标记一个事务的开始 　　　　（4）UNWATCH：取消WATCH命令对所有 key 的监视 　　　　（5）WATCH key [key...]：监视一个（或多个）key，如果在事务之前执行这个（或者这些）key被其他命令所改动，那么事务将会被打断。 　　2、事务报错问题： 　　　　（1）语句错误：会直接在添加队列的时候报错，如果出现这个错误，则整个事务都会回滚 　　　　（2）逻辑错误：例如给一个字符串 + 1，在执行的时候才会报错。这种错误则不会影响事务中的其他操作，只有本条会报错 　　3、watch 监控： 　　　　（1）乐观锁： 　　　　　　　　乐观锁（Optimistic Lock），是一个乐观的锁，每次去拿数的时候都认为别人不会对数据进行修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用“版本号

场景: (User Service) 更新用户操作包含更新用户基本属性和分配角色,由两个线程分别执行,当一个线程执行成功另一个执行失败时,需要回滚整个处理流程 解决方案: 使用CQRS事件溯源回滚聚合根到指定状态 事件溯源(Event Source): 事件溯源能够保证对应用状态所有的改变被当作一系列的事件存储起来,我们不仅仅能查询这些事件,我们还能利用这些事件记录还原应用过去的状态,并作为自动调整状态以应对追溯性变化的基础. 逻辑分析: 更新用户无论是更新用户基本属性还是分配角色,我们期望是从上一次对这个聚合根实例状态的改变节点开始, 比如第一次创建一个UserAggregate实例 {name=zhngsan,phone=123,assignedRoleList=[r01,r02,r03]},后来更新了这个聚合根实例将assigedRoleList属性从[r01,r02,r03]更新为[r01,r04]此时UserAggregate变为{name=zhngsan,phone=123,assignedRoleList=[r01,04]},假如又要对这个聚合根实例更新,那么我们期望从上一次assigedRoleList属性为[r01,r04]这个节点开始更新. 怎样得到过去某个状态改变的聚合根实例? 我们尝试通过调用AXON load()方法得到一个UserAggregate

原文链接：https://blog.ouyangsihai.cn/ >> MySQL事务，这篇文章就够了 在看这篇文章之前，我们回顾一下前面的几篇关于MySQL的系列文章，应该对你读下面的文章有所帮助。 InnoDB与MyISAM等存储引擎对比 面试官问你B树和B 树，就把这篇文章丢给他 MySQL的B 树索引的概念、使用、优化及使用场景 MySQL全文索引最强教程 MySQL的又一神器-锁，MySQL面试必备 0 什么是事务 事务（Transaction） 是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都 执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每 个事务结束时，都能保持数据一致性。 同时，事务有着严格的地定义，必须满足四个特性，也就是我们一直说的ACID，但是，并不是说各种数据库就一定会满足四个特性，对于不同的数据库的实现来说，在不同程度上是不一定完全满足要求的，比如，Oracle数据库来说，默认的事务隔离级别是 READ COMMITTED ，是不满足隔离性的要求的。 下面我们趁热打铁，介绍一下事务的必知必会的四大特性，这几个特性也是在面试中，面试官面试MySQL的相关知识的时候，问的比较多的问题，所以，这几个特性务必需要理解并且透彻的记在心里，开个玩笑，被火车撞了，也不应该忘记这四个特性！ 1 事务的四大特性

一、事务的基本要素（ ACID ） 　　 1 、原子性（ Atomicity ）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 　　 2 、一致性（ Consistency ）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如 A 向 B 转账，不可能 A 扣了钱， B 却没收到。 　　 3 、隔离性（ Isolation ）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如 A 正在从一张银行卡中取钱，在 A 取钱的过程结束前， B 不能向这张卡转账。 　　 4 、持久性（ Durability ）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 二、事务的并发问题 　　 1 、脏读：事务 A 读取了事务 B 更新的数据，然后 B 回滚操作，那么 A 读取到的数据是脏数据 　　 2 、不可重复读：事务 A 多次读取同一数据，事务 B 在事务 A 多次读取的过程中，对数据作了更新并提交，导致事务 A 多次读取同一数据时，结果 不一致。 　　 3 、幻读：系统管理员 A 将数据库中所有学生的成绩从具体分数改为 ABCDE 等级，但是系统管理员 B

一、git怎么回退到某个历史版本 首先在 code.aliyun.com 的找到你所要回滚的分支提交记录，点击右侧红框中的连接即可得到 提交记录编号，截图如下： 2. 在Terminal 或者git控制条 执行 回退到某个版本命令 git reset --hard 139dcfaa558e3276b30b6b2e5cbbb9c00bbdca96 3. 强制提交到master_ptu分支（具体需要提交到哪个分支请酌情修改，此例为提交到 master_ptu分支） git push -f -u origin master_ptu 二、回退时的注意事项 1. 执行以上脚本前 一定 记得 做个 分支的备份 2. 涉及到多个分支合并后 又想回滚代码的，请注意提交记录编号的选择，请一定选择 当前分支的提交记录编号，否则可能会回滚成其它分支的编号，例如我打算回滚到 master_ptu的某个历史版本： git reset --hard 139dcfaa558e3276b30b6b2e5cbbb9c00bbdca96 139dcfaa558e3276b30b6b2e5cbbb9c00bbdca96 一定得是 直接在master_ptu上的直接提交记录编号，否则会回滚成 其它分支的某个版本。 执行以下脚本前 一定 记得 做个 分支的备份 回退到某个版本（最后的一串字符是 版本变更编号

一、介绍 @Transactional是建立在AOP基础上的，它的本质是对方法的前后进行拦截，在目标方法开始前创建一个事务，在目标方法运行结束时根据运行的情况进行提交或者回滚操作。使用@Transactional不会对代码造成污染，使用起来简单便捷。 二、相关的配置 readOnly：该属性用于设置当前事务是否为只读事务，设置为true表示只读，false则表示可读写，默认值为false。例如：@Transactional(readOnly=true)； rollbackFor： 该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。例如：指定单一异常类：@Transactional(rollbackFor=RuntimeException.class)指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})； rollbackForClassName： 该属性用于设置需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，则进行事务回滚。例如：指定单一异常类名称@Transactional(rollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional

先切换到指定分支:该分支必须是非受保护的分支，才能推送远程成功； 回滚到指定的版本 e377f60e28c8b84158:指定的版； git reset --hard e377f60e28c8b84158； git push -f origin 指定分支 来源： https://www.cnblogs.com/dongjiang/p/11413872.html

作者：张乘辉 前言 在微服务架构体系下，我们可以按照业务模块分层设计，单独部署，减轻了服务部署压力，也解耦了业务的耦合，避免了应用逐渐变成一个庞然怪物，从而可以轻松扩展，在某些服务出现故障时也不会影响其它服务的正常运行。总之，微服务在业务的高速发展中带给我们越来越多的优势，但是微服务并不是十全十美，因此不能盲目过度滥用，它有很多不足，而且会给系统带来一定的复杂度，其中伴随而来的分布式事务问题，是微服务架构体系下必然需要处理的一个痛点，也是业界一直关注的一个领域，因此也出现了诸如 CAP 和 BASE 等理论。 在今年年初，阿里开源了一个分布式事务中间件，起初起名为 Fescar，后改名为 Seata，在它开源之初，我就知道它肯定要火，因为这是一个解决痛点的开源项目，Seata 一开始就是冲着对业务无侵入与高性能方向走，这正是我们对解决分布式事务问题迫切的需求。 分布式事务解决的方案有哪些？ 目前分布式事务解决的方案主要有对业务无入侵和有入侵的方案，无入侵方案主要有基于数据库 XA 协议的两段式提交（2PC）方案，它的优点是对业务代码无入侵，但是它的缺点也是很明显：必须要求数据库对 XA 协议的支持，且由于 XA 协议自身的特点，它会造成事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，因此它性能很差，它的存在相当于七伤拳那样“伤人七分，损己三分”

1、Spring声明式事务配置的五种方式 　　前段时间对Spring的事务配置做了比较深入的研究，在此之前对Spring的事务配置虽说也配置过，但是一直没有一个清楚的认识。通过这次的学习发觉Spring的事务配置只要把思路理清，还是比较好掌握的。 　　总结如下： 　　Spring配置文件中关于事务配置总是由三个组成部分，分别是DataSource、TransactionManager和代理机制这三部分，无论哪种配置方式，一般变化的只是代理机制这部分。 　　DataSource、TransactionManager这两部分只是会根据数据访问方式有所变化，比如使用Hibernate进行数据访问时，DataSource实际为SessionFactory，TransactionManager的实现为HibernateTransactionManager。 　　具体如下图： 　　根据代理机制的不同，总结了五种Spring事务的配置方式，配置文件如下： 第一种方式：每个Bean都有一个代理 <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"