回滚

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

相信小伙伴们对git不陌生吧，但是究竟git是怎么样工作的，它的构成又是怎么样的呢？我们来看看： 上图很明显的说明，git是又4个部分组成的： 工作区域--add-->暂存区域--commit-->本地版本仓库--push-->远程版本仓库 基本指令 1. add git add -u：将文件的修改、文件的删除，添加到暂存区。 git add .：将文件的修改，文件的新建，添加到暂存区。 git add -A：将文件的修改，文件的删除，文件的新建，添加到暂存区。 虽然网上是如上这么说，但是我试过好像git add . 和git add -A 效果是一样的。 2.commit commit -m：把暂存区的内容提交到本地版本区 commit -a -m：相当于git add -u和git commit -m组合 3.log 可以查看每个commit的版本号： 4.reflog 和log很像，比log能看得更多，git reset也可以看到 5.reset reset: "git reset --hard 版本号 " 执行这句就可以回滚代码回到对应的版本了，我们常用回滚 本地分支 的代码 其中版本号是上面红框的随机字符串，和git log的commit右边的字符串，一般取开头的几位就ok了 例如git reset --hard ad208 6.revert revert:也是回滚版本

引用： https://www.cnblogs.com/vipstone/p/9350075.html 引言 根据前面的知识（ 深入了解RabbitMQ工作原理及简单使用 、 Rabbit的几种工作模式介绍与实践 ）我们知道，如果要保证消息的可靠性，需要对消息进行持久化处理，然而消息持久化除了需要代码的设置之外，还有一个重要步骤是至关重要的，那就是保证你的消息顺利进入Broker（代理服务器），如图所示： 正常情况下，如果消息经过交换器进入队列就可以完成消息的持久化，但如果消息在没有到达broker之前出现意外，那就造成消息丢失，有没有办法可以解决这个问题？ RabbitMQ有两种方式来解决这个问题： 通过AMQP提供的事务机制实现； 使用发送者确认模式实现； 一、事务使用 事务的实现主要是对信道（Channel）的设置，主要的方法有三个： channel.txSelect()声明启动事务模式； channel.txComment()提交事务； channel.txRollback()回滚事务； 从上面的可以看出事务都是以tx开头的，tx应该是transaction extend（事务扩展模块）的缩写，如果有准确的解释欢迎在博客下留言。 我们来看具体的代码实现： // 创建连接 ConnectionFactory factory = new ConnectionFactory();

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

　　　　自己的主机上的Hadoop版本是2.7.6，是测试用的伪分布式Hadoop，在前段时间部署了Hive on Spark，但由于没有做好功课，导致了Hive无法正常启动，原因在于Hive 3.x版本不适配Hadoop 2.x版本。之前我在学校服务器上部署的Hadoop版本是3.1.2，现打算将自己的从2.7.6升级到3.1.2版本，同时也当作练练手并记录以便以后参考。 　　这是一个大版本跨度的升级操作，所以先参考Hadoop权威指南上的方案以及 官方文档 ，然后拟定了升级和回滚方案。 　　根据官方文档所说： ”For non-HA clusters, it is impossible to upgrade HDFS without downtime since it requires restarting the namenodes. However, datanodes can still be upgraded in a rolling manner.“ 也就是说对于非HA群集， 由于需要重新启动名称节点，因此无法在没有停机的情况下升级HDFS。 但是，仍可以回滚方式升级datanode。 　　Hadoop升级最主要是HDFS的升级，HDFS的升级是否成功，才是升级的关键，如果升级出现数据丢失，则其他升级就变得毫无意义。 　　解决方法：

关于定时发短信业务的讨论 事情的起因 需求：在每次线下活动的开始的前一天晚上七点给报名参加价值研习社的用户发一条通知短信用户记得准时参加活动。 备注：因为我们的业务并发不是很大，所以很多场景并没有考虑到并发情况下的一些问题，这个需求正好通过crontab执行，并且加上服务器的自动弹性伸缩，所以相当于模拟了一次并发的业务场景。 先简单介绍一下数据库的表结构： 这几个方案都依赖每天晚上七点执行一次corntab。 方案1 根据开讲时间查询活动表是否有满足条件的线下活动，如果有的话，再通过活动id关联到签到表过滤出send_sms字段为0的uid并关联用户表拿出手机号等信息。发送完成后再统一更新send_sms字段。 缺点：在并发业务场景下，可能会产生脏读的情况，造成发送多次短信的情况。 方案2 与方案1很相似，唯一的区别就是查询的时候开启事务用 SELECT ... FOR UPDATE ，这种查询语句的区别就是在 SELECT 的时候把结果行上锁，从而就能避免脏读，然后再同一个事务中 UPDATE send_sms字段，最后 commit 。 缺点：由于发短信不是数据库操作，不可回滚。所以如果执行的过程中发生回滚，就会出现短信已经发出去了，但是数据库发生回滚，send_sms字段置为了0，这就产生了矛盾。而且如果是个耗时的任务可能会出现死锁的问题。 以下就是执行的逻辑 BEGIN;

一、分布式锁 　　分布式锁是在分布式场景下一种常见技术，通常通过基于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节点上创建锁，过期时间较短

事务的用途这里就不赘述了。在一些大型项目安全性强项目用途还是比较广泛的。 在执行银行转账操作的时候，A用户向B用户转账1000元。 -- begin transaction -- 打开一个事务,简写可以用begin tran -- @@error范围错误码,如果没错误就返回0 begin tran declare @sum int update employees set balance = balance - 1000 where id = 1 set @sum = @sum + @@error update employees set balance = balance + 1000 where id = 2 set @sum = @sum + @@error if @sum <> 0 begin rollback print ' 回滚了 ' ; end else commit 每条修改sql语句后面加上@@error（系统变量）来统计是否有错误出现。如果没有错误sum执行完是0，反则不是0.这样就能判断在sql语句的修改过程中是否有错误。 没有问题就提交事务，有问题就回滚事务。 事务的提交或回滚操作，也可以放到try catch里，如果有异常就roll back ，没有异常就commit 可以定义事务的名称，在定义多个事务中，可以指定回滚或提交哪个事务 roll back

一、一些概念 声明式的事务管理是基于AOP的，在springboot中可以通过@Transactional注解的方式获得支持，这种方式的优点是： 1）非侵入式，业务逻辑不受事务管理代码的污染。 2）方法级别的事务回滚，合理划分方法的粒度可以做到符合各种业务场景的事务管理。 本文使用目前最常用的mybatis框架来配置springboot的事务管理机制。下面进入配置方法介绍。 二、开启事务 一个注解很简单 @EnableTransactionManagement //开始事务 三、Service 在设计service层的时候，应该合理的抽象出方法包含的内容。 然后将方法用@Trasactional注解注释，默认的话在抛出Exception.class异常的时候，就会触发方法中所有数据库操作回滚，当然这指的是增、删、改。 当然，@Transational方法是可以带参数的，具体的参数解释如下： 属性 类型 描述 value String 可选的限定描述符，指定使用的事务管理器 propagation enum: Propagation 可选的事务传播行为设置 isolation enum: Isolation 可选的事务隔离级别设置 readOnly boolean 读写或只读事务，默认读写 timeout int (in seconds granularity) 事务超时时间设置

Mysql隔离性之Undo Log InnoDB行记录有三个隐藏字段：分别对应的行的rowid、事务号db_trx_id和回滚指针db_roll_ptr，其中db_trx_id表示最近修改的事务的id，db_roll_ptr指向回滚段中的undo log。 根据行为不同，可以分为两种：insert undo log 和 update undo log insert undo log： 在insert操作中产生undo log，因为insert操作的记录只对事务本身可见，rollback在该事务中直接删除，不需要进行purge操作。 update undo log： 在update or delete操作中产生undo log，因为会对已存在的记录产生影响，rollback MVCC机制会找它的历史版本进行恢复。 在update or delete操作中产生undo log，因为会对已存在的记录产生影响，为了提供MVCC机制，因此update undo log不能在事务提交的时候删除，而是在事务提交时，把事务放入histroy list上，等待purge线程进行最后的删除操作。 如下图所示（初始状态）： 当事务 2 使用 UPDATE 语句修改该行数据时，会首先使用排他锁锁定改行，将该行当前的值复制到 undo log 中，然后再真正地修改当前行的值，最后填写事务 ID