事务回滚

应用场景： 银行取钱，从ATM机取钱，分为以下几个步骤 1 登陆ATM机，输入密码； 2 连接数据库，验证密码； 3 验证成功，获得用户信息，比如存款余额等； 4 用户输入需要取款的金额，按下确认键； 5 从后台数据库中减掉用户账户上的对应金额； 6 ATM吐出钱； 7 用户把钱拿走。 对于上面的取钱这个事情，如果有一步出现错误的话，那么就会取消整个取钱的动作，但是如果在第5步，系统后台已经把钱减了，但是ATM机没有取出来，那么就应用到mysql中的事务。简单地 来说，就是取钱这7步要么都完成，要么就啥也不做，在数据库中就是这个道理。 事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位，事务回滚是指将该事务已经完成的对数据库的更新操作撤销，在事务中，每个正确的原子 操作都会被顺序执行，直到遇到错误的原子操作。回滚的意思其实即使如果之前是插入操作的话，那么会执行删除之前插入的记录，如果是修改操作的话，那么会执行将update之前的记录还原。 因此，正确的原子操作是真正被执行过的，是物理执行。 事务是由一条或者多条sql语句组成，在事务的操作中，要么这些sql语句都执行，要么都不执行。 事务的ACID特性:原子性，一致性，隔离性，持久性。 在当前事务中确实能看到插入的记录，最后只不过被删除了，但是auto_increament不会删除而是改变值

1.学习链接: https://www.cnblogs.com/xd502djj/p/10940627.htmlhttps://www.cnblogs.com/caoyc/p/5632963.htmhttps://www.cnblogs.com/chengshun/p/9778880.html 2.事物场景: https://blog.csdn.net/kiwi_coder/article/details/20214939 3.参数: 4.注意的几点: 　　1、@Transactional 只能被应用到public方法上, 对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能. 　　2、用 spring 事务管理器,由spring来负责数据库的打开,提交,回滚.默认遇到运行期例外(throw new RuntimeException("注释");)会回滚，即遇到不受检查（unchecked）的例外时回滚；而遇到需要捕获的例外(throw new Exception("注释");)不会回滚,即遇到受检查的例外（就是非运行时抛出的异常，编译器会检查到的异常叫受检查例外或说受检查异常）时，需我们指定方式来让事务回滚要想所有异常都回滚,要加上 @Transactional( rollbackFor={Exception.class,其它异常})

1.spring boot 中事物的使用 （当前指代的不是多数据源，只有一个数据源的前提下） <1> 在springboot 启动类上加上允许使用事物注解 @EnableTransactionManagement <2> 就这么简单的一个操作，更主要的是了解@Transactional 的一些特性，到底该怎么使用，什么时候使用。 事物的四个特性想必大家应该都知道，原子性（最小的整体，不可分割），一致性（都成功或都失败），隔离性（事物间互不干扰），持久性（保存的数据库）。 原子性 （atomicity）:强调事务的不可分割。 一致性 （consistency）:事务的执行的前后数据的完整性保持一致。 隔离性 （isolation）:一个事务执行的过程中,不应该受到其他事务的干扰 。 持久性（durability） :事务一旦结束,数据就持久到数据库。 <3> 进到@Transactional 注解中看一下 propagation:该属性用于设置事务的传播行为。 isolation:该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置 timeout:该属性用于设置事务的超时秒数（单位为秒），默认值为-1表示永不超时 readOnly：该属性用于设置当前事务是否为只读事务，设置为true表示只读

分布式场景常见问题及解决方案 前言: 本文主要是根据平常学习过程中遇到的一些分布式场景常见问题，并作出了解析，有不对或者需要补充的地方，希望广大的程序员朋友们及时改进，另外，想要学习，分布式的朋友，我提供一张分布式的学习路线思维导图，望可以给你们一点建议。 下面进入正题 一、分布式锁 分布式锁是在分布式场景下一种常见技术，通常通过基于redis和zookeeper来实现，本文主要介绍redis分布式锁和zookeeper分布式锁的实现方案和对比： （1）基于redis的普通实现 这个方案的加锁主要实现是基于redis的”SET key 随机值 NX PX 过期时间（毫秒）”指令，NX代表只有key不存在时才设置成功，PX代表在过期时间后会自动释放。 这个方案的释放锁是通过lua脚本删除key的方式，判断value一样则删除key。 使用随机值的原因是如果某个获取到锁的客户端阻塞了很长时间，导致了它获取到的锁已经自动释放，此时可能有其他客户端已经获取到了锁，如果直接删除是有问题的，所以要通过随机值加上lua脚本去判断如果value相等时再删除。 这个方案存在一个问题就是，如果采用redis单实例可能会存在单点故障问题，但如果采用普通主从方式，如果主节点挂了key还没来得及同步到从节点，此时从节点被切换到了主节点，由于没有同步到数据别人就会拿到锁。 （2）redis的RedLock算法

相关命令DISCARD,EXEC,MULTI,UNWATCH,WATCH redis不支持回滚 基本使用示例MULTI EXEC 不支持回滚示例 t3的值成功赋值，没有回滚 WATCH 乐观锁 watch监控的key，若发生变动，则在事务中对其修改时，事务不执行 UNWATCH DISCARD 放弃事务 来源： https://www.cnblogs.com/sunang/p/11343749.html

难点重点 回滚实物rollback 提交事务commit 在数据更新时,oracle会默认开始一个数据库事务,在这个事务没有提交以前,其他人或其他窗口查询不到这里新增或修改的数据 --这种现象称为数据库的锁---数据查询不到,因为该行数据表被锁住了,称为行级锁. --在进行数据库操作时,数据一会可见,一会不可见这样的现象称为:脏读 --脏读什么时候出现?在更新数据时,如果发生了事务的回滚,且在事务回滚前进行了数据的查询,这样的查询就会造成数据的脏读. --回滚事务使用rollback命令 rollback;--事务一旦回滚,则事务结束,当前更新的数据会回滚更新之前.且不能再提交 --执行数据更新后,如果没有问题时需要提价事务,提交事务使用commit命令 --数据一旦提交,则永久性保存到数据库中(一旦提交则事务结束,不能再回滚) commit; --数据事务的几个特性 --原子性 :执行数据更新时,要么一起成功要么一起失败.即在事务中的更新操作时一个不可分割的原子操作. --一致性:在事务操作的前后(回滚前后,提交前后),每次查询到的数据都是一样的. --开始事务前,每次查询到的数据一定是相同的;回滚事务后,每次查询到的数据一定是相同的;提交事务后,每次查询到的数据一定是相同的; --隔离性:事务一旦开启,如果没有提交或回滚,其他窗口(事务)是无法看到当前事务修改后的内容的 -

背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 一、概念 事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。 银行在两个账户之间转账，从A账户转入B账户1000元，系统先减少A账户的1000元，然后再为B账号增加1000元。如果全部执行成功，数据库处于一致性；如果仅执行完A账户金额的修改，而没有增加B账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让A账户钱扣了，但是中途某些操作失败了，导致B账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？因此简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。 接下来会以InnoDB为例，抽丝剥茧MySQL在事务支持方面的特定实现。 二、隔离性与隔离级别

今天在开发公司spring项目时，发现事务失效，即@Transactional注解无法起效，查阅资料后发现原因有一下几点： 1.spring的事务默认只支持抛出runtime异常，如果要捕获exception，则需要指定异常类 @Transactional(rollbackFor = Exception.class)。 2.被try catch捕获的异常无法自动回滚，需要自己手动在catch时进行回滚。 3.service上需要加上注解@EnableTransactionManagement开启注解事务管理，等同于在xml中配置 <tx:annotation-driven transaction-manager=“transactionManager” /> 来源： CSDN 作者： Nekoprpr 链接： https://blog.csdn.net/weixin_42400252/article/details/103242500

Spring事务的基本原理 Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。对于纯JDBC操作数据库，想要用到事务，可以按照以下步骤进行： 获取连接 Connection con = DriverManager.getConnection() 开启事务con.setAutoCommit(true/false); 执行CRUD 提交事务/回滚事务 con.commit() / con.rollback(); 关闭连接 conn.close(); 使用Spring的事务管理功能后，我们可以不再写步骤 2 和 4 的代码，而是由Spirng 自动完成。那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢？解决这个问题，也就可以从整体上理解Spring的事务管理实现原理了。下面简单地介绍下，注解方式为例子 配置文件开启注解驱动，在相关的类和方法上通过注解@Transactional标识。 spring 在启动的时候会去解析生成相关的bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据@Transaction的相关参数进行相关配置注入，这样就在代理中为我们把相关的事务处理掉了（开启正常提交事务，异常回滚事务）。 真正的数据库层的事务提交和回滚是通过binlog或者redo

一、分布式锁 　　分布式锁是在分布式场景下一种常见技术，通常通过基于redis和zookeeper来实现，本文主要介绍redis分布式锁和zookeeper分布式锁的实现方案和对比： 　　（1）基于redis的普通实现 　　这个方案的加锁主要实现是基于redis的”SET key 随机值 NX PX 过期时间（毫秒）”指令，NX代表只有key不存在时才设置成功，PX代表在过期时间后会自动释放。 　　这个方案的释放锁是通过lua脚本删除key的方式，判断value一样则删除key。 　　使用随机值的原因是如果某个获取到锁的客户端阻塞了很长时间，导致了它获取到的锁已经自动释放，此时可能有其他客户端已经获取到了锁，如果直接删除是有问题的，所以要通过随机值加上lua脚本去判断如果value相等时再删除。 　　这个方案存在一个问题就是，如果采用redis单实例可能会存在单点故障问题，但如果采用普通主从方式，如果主节点挂了key还没来得及同步到从节点，此时从节点被切换到了主节点，由于没有同步到数据别人就会拿到锁。 　　（2）redis的RedLock算法 　　这个方案是redis官方推荐的分布式锁的解决方案，假设有5个redis master实例，然后执行如下步骤去获取一把锁： 　　1）获取当前时间戳，单位是毫秒 　　2）跟上面类似，轮流尝试在每个master节点上创建锁，过期时间较短