回滚

Django 中事务的使用 Django默认的事务行为 默认情况下，在Django中事务是自动提交的。当我们运行Django内置的模板修改函数时，例如调用model.save()或model.delete()时，事务将被立即提交。这种机制和数据库的自动提交事务机制类似。记住这里没有默认的回滚机制 在HTTP请求上加事务 对于Web请求，Django官方推荐使用中件间TransactionMiddleware来处理请求和响应中的事务。它的工作原理是这样的：当一个请求到来时，Django开始一个事务，如果响应没有出错，Django提交这期间所有的事务，如果view中的函数抛出异常，那么Django会回滚这之间的事务。 为了实现这个特性，需要在MIDDLEWARE_CLASSES setting中添加TransactionMiddleware： MIDDLEWARE_CLASSES = ( 'django.middleware.cache.UpdateCacheMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.transaction.TransactionMiddleware

谈谈业务中使用分布式的场景 首先，需要了解系统为什么使用分布式。 随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面： 1.应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。 2.底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。 #场景1：应用系统集群的 Session 共享 应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。 #场景2：应用系统的服务化拆分 服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。 #场景3：底层数据库的压力分摊 如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。 Session 分布式方案 #基于 nfs(net filesystem) 的 Session 共享 将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制

MySQL 原理篇 MySQL 索引机制 MySQL 体系结构及存储引擎 MySQL 语句执行过程详解 MySQL 执行计划详解 MySQL InnoDB 缓冲池 MySQL InnoDB 事务 MySQL InnoDB 锁 MySQL InnoDB MVCC MySQL InnoDB 实现高并发原理 MySQL InnoDB 快照读在RR和RC下有何差异 转载： 《InnoDB并发如此高，原因竟然在这？》 并发控制 为啥要进行并发控制？ 并发的任务对同一个临界资源进行操作，如果不采取措施，可能导致不一致，故必须进行并发控制（Concurrency Control）。 技术上，通常如何进行并发控制？ 通过并发控制保证数据一致性的常见手段有： 锁（Locking） 数据多版本（Multi Versioning） 锁 如何使用普通锁保证一致性？ 操作数据前，锁住，实施互斥，不允许其他的并发任务操作； 操作完成后，释放锁，让其他任务执行； 如此这般，来保证一致性。 普通锁存在什么问题？ 简单的锁住太过粗暴，连“读任务”也无法并行，任务执行过程本质上是串行的。 于是出现了共享锁与排他锁： 共享锁（Share Locks，记为S锁），读取数据时加S锁 排他锁（eXclusive Locks，记为X锁），修改数据时加X锁 共享锁与排他锁的玩法是： 共享锁之间不互斥，简记为：读读可以并行

应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。 长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。 一、 蓝绿发布 项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。 当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。 最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。 特点 如果出问题，影响范围较大； 发布策略简单； 用户无感知，平滑过渡； 升级/回滚速度快。 缺点 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发； 短时间内浪费一定资源成本； 基础设施无改动，增大升级稳定性。 蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。 二、 灰度发布 灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。 特点 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控； 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小

【注意： 如果提交的错误代码较少，可以在本地修改成 commit之前的正确代码样子，然后再提交一次即可。不用麻烦的操作回滚。 】 开发人员错误将代码提交到gitlab的远程dev分支，回滚方法如下： 1、本地回滚 进入git bash，进入该工程目录： leichen@N MINGW64 ~ $ cd c: leichen@N-5C MINGW64 /c $ cd git_home leichen@N-5C MINGW64 /c/git_home $ cd zntp leichen@N-5C MINGW64 /c/git_home/zntp (dev) $ git log commit 095d0ada370c32ace4fd2ebcd4372beea9a64f77 Author: MirGao <Mir_Gao15517374303@163.com> Date: Fri Nov 23 16:50:28 2018 +0800 实现接口数量7个 commit b8b9fa09775a511d522e584a3be6817c9de7e43b Author: PC-20180625CLEK\Administrator <18510942269@163.com> Date: Mon Oct 15 14:58:07 2018 +0800 bug修改 确认回滚到版本“commit” =

Git介绍 　　Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。 　　什么是“版本控制”？我为什么要关心它呢？ 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 　　Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，所以，工作的时候就不需要联网了，因为版本库都是在自己的电脑 上。现在每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。 　　主要有如下特点： 　　1. 版本控制 　　2. 分布式 　　3. 工作过程是将服务器上的代码下载到本地，本地开发完成后，在提交到服务器端 Git和SVN的对比 　　1.git是分布式的,svn是集中式的。(最核心) 　　2.git是每个历史版本都存储完整的文件,便于恢复,svn是存储差异文件,历史版本不可恢复。(核心) 　　3.git可离线完成大部分操作,svn则不能。 　　4.git有着更优雅的分支和合并实现。 　　5.git有着更强的撤销修改和修改历史版本的能力 　　6

声明式事务的五大属性 1.传播机制（propagation） 指的是一个带有事务的方法A运行在另一个带有事务的方法B内部时，内层方法A是使用自己的事务还 是使用外层B的事务 required:默认值，表示如果外层方法B有事务，就使用外层方法B的事务，没有就使用自己的事务 requires_new:无论外层方法B有没有事务，内层方法A都使用自己的事务 supports:表示如果外层方法B有事务，就使用外层方法B的事务，如果外层方法B没有事务，就不使用事务 2.隔离级别(isolation):是针对数据库的并发访问的，不同的隔离级别，数据库有着不同的解决方法。 repeatable_read: 默认是 可重复度 read_uncommitted:读未提交 read_committed:读已提交 serializable:串行化读：就是如果设置了这个注解，运行期间就不允许改变值 也就是不允许并发操作。 3.回滚机制 通常只有运行时异常会自动回滚，编译时异常不会回滚，想要让其回滚只有设置rollbackFor rollbackFor ={一个异常类的字节码} 就是在事务后面的参数列表里面加上 一个异常类的字节码，当你下面遇到这样的异常时 会回滚 no rollbackFor 就是即使是运行时异常，后面如果不想让其回滚，就在事务后加上norollbackFor={运行时异常的类字节码}

svn 文件冲突： D C 文件名 　　 > local unversioned, incoming file add upon update svn revert 文件名 提示： 已恢复“文件名” 顺便了解下：svn revert 用法。 revert 用于回滚。 修改过的东西没有递交(commit)，这种情况下revert会取消之前的修改 用法：#svn revert [-R] xxx_file_dir 如果需要回滚的是一个目录则加上-R（递归）可选参数回滚已提交的版本使用 svn merge svn merge -r 当前版本号:需回滚的版本号 文件 　　 　　 来源： https://www.cnblogs.com/qpjiang/p/11867844.html

给予消息队列实现分布式事务 场景: 订单系统产生订单,购物车系统减购物车中的商。 实现思路 : 订单系统在消息队列上开启一个事务（没有创建订单）。 订单系统给消息服务器发送一个“半消息”，这个半消息不是说消息内容不完整，它包含的内容就是完整的消息内容，半消息和普通消息的唯一区别是，在事务提交之前，对于消费者来说，这个消息是不可见的。 半消息发送成功后，订单系统就可以执行本地事务了，在订单库中创建一条订单记录，并提交订单库的数据库事务。 然后根据本地事务的执行结果决定提交或者回滚事务消息。如果订单创建成功，那就提交事务消息，购物车系统就可以消费到这条消息继续后续的流程。如果订单创建失败，那就回滚事务消息，购物车系统就不会收到这条消息。 橙色和绿色分别是两个事务。 问题: 步骤4事务提交失败；这时候订单系统本地事务已提交尔购物车系统没有收到消息，造成数据不一致。 如何解決消息队列事务提交过程出现的异常: kafka会直接抛出异常用户自行处理; 在RocketMQ中的事务实现中,增加了 事务反查 的机制来解决事务消息提交失败的问题 , RocketMQ的Broker没有收到提交或者回滚的请求,Broker会定期去producer上反查这个事务对应的本地事务的状态,然后根据反查结果决定提交或者回滚这个事务。 为了支持事务反查机制

  1. 背景介绍   本文基于快递包裹取件(用户获取包裹并将包裹信息存储数据库)和包裹入库(快递员将包裹放入收发室并将包裹信息存储如数据库)场景，并将包裹入库信息和取件信息分别存入不同的数据库。这样当用户取件时，需要更新两个表信息(入库表中的包裹状态和取件表中插入取件信息)。   2. 问题描述   在采用 SSM 框架搭建后端服务时，若 Service 层业务逻辑较复杂，一条业务逻辑中可能会调用多个 dao 层更改数据库的接口。此时若采用 Spring 自带的 @Transactional 注解进行事务处理，将难以满足业务需求。正如代码块1所示： 代码块1 packet com.example.pickup; public interface PickUpDao{ @Delete("delete from pickup where orderNum=#{orderNum}") public int removePickUpPacket(String orderNum) } packet com.example.storage; public interface StorageDao{ @Update("update storage set isPickup=false where orderNum=#{orderNum}") public int