回滚

情景描述 在将项目share到github后（已经push），发现push的文件中含有敏感的信息，所以想回滚状态到之前的版本。但使用log命令可以发现当前仅有一个commit状态： Yitian-MacBook-Pro:springboot-learning yitian$ git log commit f8e6d2455c8f494b860d0bb9a4b103624d75ef2a (HEAD -> master, origin/master) Author: yitian <yitian.z@foxmail.com> Date: Sat Feb 1 20:49:07 2020 +0800 init commit 使用reset命令无法回退到上次的提交状态（因为仅有一次提交，HEAD^状态并不存在），所以该方法不行。 解决方法 执行下面的命令，清除所有提交的版本并清空工作空间，这样就可以再进行第一次提交了： git update-ref -d HEAD 执行之后，将文件中敏感信息去掉之后commit并push，应该会出现如下的问题： Yitian-MacBook-Pro:springboot-learning yitian$ git push To https://github.com/Yitian-Zhang/springboot-learning.git !

今天的文章咱们聊的是分布式原理当中的 原子性 ，也称为 分布式事务 。不知道会不会有人觉得奇怪，分布式系统CAP原则当中并没有原子性，这个原子性是从哪里冒出来的？ 其实并不奇怪，之前我们在介绍各种一致性原则的时候，虽然没有明确提出来，但是原子性的相关内容已经隐藏在其中了。让我们回顾一下，分布式系统当中的一致性简单可以分为 强一致性和弱一致性 。强一致性很好理解，简单可以理解成 主节点每次更新都通过同步的方式，同步更新所有副本 。而弱一致性则是统称所有不满足强一致性的模型，可以简单理解成 通过异步更新的方式实现的一致性模型 。 想象一下更新的时候，有节点出错的情况。如果是强一致性，很好办，因为我们采用同步更新，所以更新失败的话，主节点立刻就能感知。要么 重试这次的更新 ，要么 回滚放弃 ，或者是 判断该从库是否已经宕机 ，将它 移除资源池 。 如果是异步的更新机制就麻烦了，因为没有一个统筹大局的主库了。 没有节点知道其他节点更新成功了没有 ，如果部分成功了，部分失败了，那么数据的一致性就完全没办法保障了，脏数据到处都是，这个系统也就没法用了。所以必须要保证即使是异步更新，也要做到原子性，要么所有节点一起更新成功，要么一起失败回滚，不允许出现一部分成功了，另一部分没有的情况。 那么怎么解决这个问题呢？这就需要用到 两阶段提交协议 了。 两阶段提交 两阶段提交协议的算法思路其实不难

本文始发于个人公众号： TechFlow 今天的文章咱们聊的是分布式原理当中的 原子性 ，也称为 分布式事务 。不知道会不会有人觉得奇怪，分布式系统CAP原则当中并没有原子性，这个原子性是从哪里冒出来的？ 其实并不奇怪，之前我们在介绍各种一致性原则的时候，虽然没有明确提出来，但是原子性的相关内容已经隐藏在其中了。让我们回顾一下，分布式系统当中的一致性简单可以分为强一致性和弱一致性。 强一致性 很好理解，简单可以理解成 主节点每次更新都通过同步的方式，同步更新所有副本 。而 弱一致性 则是统称所有不满足强一致性的模型，可以简单理解成 通过异步更新的方式实现的一致性模型 。 想象一下更新的时候，有节点出错的情况。如果是强一致性，很好办，因为我们采用同步更新，所以更新失败的话，主节点立刻就能感知。要么 重试这次的更新 ，要么 回滚放弃 ，或者是 判断该从库是否已经宕机 ，将它 移除资源池 。 如果是异步的更新机制就麻烦了，因为没有一个统筹大局的主库了。 没有节点知道其他节点更新成功了没 有，如果部分成功了，部分失败了，那么数据的一致性就完全没办法保障了，脏数据到处都是，这个系统也就没法用了。所以必须要保证即使是异步更新，也要做到原子性，要么所有节点一起更新成功，要么一起失败回滚，不允许出现一部分成功了，另一部分没有的情况。 那么怎么解决这个问题呢？这就需要用到 两阶段提交协议 了。

redo--> undo-->datafile insert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据. redo解释： 在Oracle数据库中，执行数据修改操作后， 并不是马上写入数据文件，而是首先生成重做信息 ，并写入SGA中的一块叫LOG_BUFFER的固定区域，LOG_BUFFER的空间并不是无限大，事实上它非常小，一般设置在3～5MB左右。LOG_BUFFER有一定的触发条件，当满足触发条件后，会有相应进程将LOG_BUFFER中的内容写入一个特定类型的文件，就是传说中的联机重做日志文件。 UNDO： undo->记录更改前的一份copy，但你系统rollback时，把这份copy重新覆盖到原来的数据 redo->记录所有操作， 用于恢复 （redo records all the database transaction used for recovery） undo->记录所有的前印象， 用于回滚 （undo is used to store uncommited data infor used for rollback） redo->已递交的事务,实例恢复时要写到数据文件去的 undo->未递交的事务. redo的原因是

使用位置 : @Transactional事务注解 既可以写在方法上也可以写在类上 @Transactional( rollbackFor = Exception.class ) 使用: 1.默认值为UncheckedException，包括了RuntimeException和Error. 2.当我们直接使用 @Transactional 不指定 rollbackFor 时，Exception及其子类都不会触发回滚 详情细节参考大佬 : https://zhuanlan.zhihu.com/p/38208248 https://www.cnblogs.com/clwydjgs/p/9317849.html 下面情况会回滚: 1.如果没有加@Transactional注解，那么这两个操作就不在一个事务里面，不具有原子性。如果deleteAll之后抛异常，那么就会导致只删除不新增。 2.加了@Transactional之后，这两个动作在一个事务里头，具有原子性，要么全部成功，要么全部失败。如果deleteAll之后抛异常，则事务回滚，恢复原先被删除的数据。 @Transactional public void deleteAllAndAddOneTransactional(Customer customer) { customerRepository.deleteAll(); if (

使用@Transactional注解声明Bean底下所有业务方法需要事务管理。 1.默认一个业务方法开启和结束事务，什么时候提交，什么时候回滚呢？ Spring容器默认情况下对于运行期异常（unchecked Exception）会进行事务回滚，如果是用户违例(checked Exception),事务不会回滚。 运行期违例：throw new RuntimeException("XXX")；运行期违例不需要使用try/catch捕捉，编译可以通过 用户违例，throw new Exception("XXX");必须使用try/catch捕捉，否则编译不能通过。 也可以修改这种行为，在业务方法上加上@Transactional(rollbackFor=Exception.class),则cheked Exception也会回滚。 如果@Transactional(noRollbackFor=RuntimeException.class)，则运行期例外也不会回滚。 2.有些业务方法不需要业务管理，如获取数据的。开启事务会对性能有影响。所以使用 @Transactional(propagation=Propagation.NOT_SUPPORTED) propagation属性指定事务的传播行为。则Spring容器在该业务方法前不会开启事务。 事务的传播属性 ： （1

简介 Python的logging模块提供了通用的日志系统，可以方便第三方模块或者是应用使用。这个模块提供不同的日志级别，并可以采用不同的方式记录日志，比如文件，HTTP GET/POST，SMTP，Socket等，甚至可以自己实现具体的日志记录方式。 logging模块与log4j的机制是一样的，只是具体的实现细节不同。模块提供logger，handler，filter，formatter。 logger 提供日志接口，供应用代码使用。logger最长用的操作有两类：配置和发送日志消息。可以通过logging.getLogger(name)获取logger对象，如果不指定name则返回root对象，多次使用相同的name调用getLogger方法返回同一个logger对象。 handler 将日志记录（log record）发送到合适的目的地（destination），比如文件，socket等。一个logger对象可以通过addHandler方法添加0到多个handler，每个handler又可以定义不同日志级别，以实现日志分级过滤显示。 filter 提供一种优雅的方式决定一个日志记录是否发送到handler。 formatter 指定日志记录输出的具体格式。formatter的构造方法需要两个参数：消息的格式字符串和日期字符串，这两个参数都是可选的。 　　与log4j类似

数据同步 的过程就是Leader服务器将那些没有在Learner服务器上提交过的事物请求同步给Learner服务器。 ZooKeeper集群数据同步通常分为四类，分别是 直接差异化同步（DIFF同步）、先回滚再差异化同步（TRUNC + DIFF同步）、仅回滚同步（TRUNC同步）和全量同步（SNAP同步） 。 peerLastZxid ：该Learner服务器最后处理的ZXID。 minCommittedLog ：Leader服务器提议缓存队列committedLog中的最下ZXID。 maxCommittedLog ：Leader服务器提议缓存队列committedLog中的最大ZXID。 1、直接差异化同步（DIFF同步） 场景： peerLastZxid介于minCommittedLog和maxCommittedLog之间。 Leader服务器会首先向Learner发送一个DIFF指令。然后，在Proposal同步过程中，针对每个Proposal，Leader服务器都会通过发送两个数据包来完成，分别是PROPOSAL内容数据包和COMMIT指令数据包——这和ZooKeeper运行时Leader和Follower之间的事物请求的提交过程是一致的。在发送完差异化数据之后，将Learner加入到forwardingFollowers或observingLearners队列中

前提 所有服务均有独立的事物管理机制,相互间没有任何关联. 所有业务接口都有对应的补偿方法,用于将已经更新的数据还原到上一次的状态. 本次实例为同步业务,理想状态下,只有全部成功或全部失败两种情况. 正式开始 正常流程 一切安好. 中途异常 - 补偿成功 虽然发生了失败,但所有补偿都成功了.没有什么问题 中途异常 - 补偿失败 此时,主服务有三种处理方法 主服务无限重试补偿方法,直到补偿成功. 这里有很麻烦的问题,如果下游的服务器已经停机,此时主服务的无限重试已经没有意义.在最坏的情况下,如果主服务访问量过大,而因为业务相同,主服务的线程池中的全部线程将全部处于阻塞状态,失去处理新请求的能力. 同时,访问主服务的客户端有可能会放弃本次的连接,导致正在重试中的线程被回收,丢失所有状态 主服务尽可能调用补偿方法,并回滚自身事物,同时通知备用方案 这里依靠备用方案对失败的补偿调用进行异步异步调用,已达到"最终一致"的效果.备用方案一般需要集成"可靠消息系统" 主服务直接放弃补偿与自身的回滚,并通知备用方案 与2基本相同.在调用链比较长的情况下且补偿随机性失败,从上层看,2方案的调用结果(备用方案未执行时)将成锯齿状.而本方案,其对应 的消费者直接以级联方式进行补偿的调用,最终完成全部补偿调用与主方法数据回滚,同样从上层看,方案3的调用结果(备用方案未执行时)将是平整的(只有失败处断裂).

InnoDB的MVCC机制 InnoDB是一个多版本的存储引擎，它保存着已经改变的行的旧版本的信息，用来支持事务的性质例如并发和回滚。这些信息存储在一个称为回滚段（roolback segment）的数据结构中。InnoDB使用回滚段中的信息来执行事务回滚所需的撤销操作。还通过这些信息来构建行的早期版本，以便进行一致性读操作。一致性读是一种增强并发性的强大技术，允许查询在不等待其他事务释放锁的情况下继续进行。 一、InnoDB的行结构 innodb存储的最基本row中包含一些额外的存储信息 DATA_TRX_ID，DATA_ROLL_PTR，DB_ROW_ID，DELETE BIT 其中： 1、6字节的DATA_TRX_ID 标记了最新更新这条行记录的transaction id，每处理一个事务，其值自动+1。 2、7字节的DATA_ROLL_PTR 指向当前记录项的rollback segment的undo log记录，找之前版本的数据就是通过这个指针。 3、6字节的DB_ROW_ID，当由innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，否则聚集索引中不包括这个值 4、DELETE BIT位用于标识该记录是否被删除，这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候。 二、撤销日志 回滚段的undo