回滚

spring 的事务xml配置(事务使用xml配置, 其他的ioc bean使用注解) 配置事务管理器 <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <!-- 引用数据源bean --> <property name="dataSource" ref="dataSource"/> </bean> 配置事务的通知 <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="*" propagation="REQUIRED" read-only="false"/> <tx:method name="get*" propagation="SUPPORTS" read-only="true"/> <tx:method name="find*" propagation="SUPPORTS" read-only="true"/> </tx:attributes> </tx:advice> 使用tx:advice标签配置事务通知 属性： id：事务的唯一标识 transaction-manager

Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和Spring框架无缝集成。 dubbo中消费者调用提供者原理 Provider:暴露服务方称之为“服务提供者” Consumer:调用远程服务方称之为“服务消费者” Registry:服务注册与发现的中心目录服务称之为“服务注册中心” Monitor:统计服务的调用次调和调用时间的日志服务称之为“服务监控中心” Provider发布后会在Registry中注册, Consumer从Registry订阅服务,一旦注册中心提供了Provider, Consumer就可以异步得到通知,从而调用Provider的功能,这两者都会在Monitor监控中心中被记录调用的信息. 消费者调用提供者如果网络断了怎么办？ 三种方案 1,dubbo部署集群,当前网络中断可在集群中匹配到其它提供者实现,如果没有找到其它提供者, 服务提供者和服务消费者仍能通过本地缓存通讯,直到网络恢复. 2 消费者在调用过程中如果得不到提供者的回馈则设定时间取消操作,事务进行回滚处理.保证事务完整性 3将请求消息放入消息队列中,提示用户操作,当提供者正常服务后进行消费,从而保证事务完整性. 如果是客户网断的情况大多不用担心，根据当前环境判断是否回滚，给出通知让用户上线后知道刚才做了什么，保留了什么

Service的流程 1.插入店铺信息->2.返回店铺Id->3.根据店铺Id创建存储图片的文件夹->4.把文件夹的地址更新回店铺信息中 只要有一步出错 就要事务回滚 创建ShopService 接口 接着写实现类ShopServiceImpl 在实现service接口中添加@Transational事务标签 只有当程序抛出RuntimeException的异常或继承RuntimeException类 时，事务才会回滚，如果只是抛出Exception，事物不会回滚 1 @Service 2 public class ShopServiceImpl implements ShopService { 3 4 @Autowired 5 private ShopDao shopDao; 6 7 @Override 8 @Transactional 9 // 1.插入店铺信息->2.返回店铺Id->3.根据店铺Id创建存储图片的文件夹->4.把文件夹的地址更新回店铺信息中 10 public ShopExecution addShop(Shop shop, CommonsMultipartFile shopImg) { 11 // 空值判定 12 if (shop == null ){ 13 return new ShopExecution( ShopStateEnum.NULL_SHOP)

1 快照的概念 一般对快照的理解就是能够将系统还原到某个瞬间，这就是快照的作用。 快照针对要保存的数据分为内存快照和磁盘快照，内存快照就是保存当前内存的数据，磁盘快照就是保存硬盘的数据。 快照针对保存方式又分为内部快照和外部快照。 内部快照：是指快照信息和虚拟机存在同一个qcow2镜像中，使用单个的 qcow2 的文件来保存快照和快照之后的改动。这种快照是 libvirt 的默认行为，现在的支持很完善（创建、回滚和删除），但是只能针对 qcow2 格式的磁盘镜像文件，而且其过程较慢等。 外部快照：是指做快照时原虚拟机的disk将变为readonly的模板镜像，然后会新建一个qcow2文件来记录与原模板镜像的差异数据，外部快照的结果是形成一个qcow2文件链：original <- snap1 <- snap2 <- snap3 2 主流libvirt快照实现介绍 2.1 libvirt的内部快照操作 以下是利用libvirt的virsh工具来创建一些内置快照： 创建虚拟机快照： virsh snapshot-create-as --name test001 --description ‘ abc ‘ instance- 00000001 列出虚拟机的快照： virsh snapshot-list instance- 00000001 查看某个快照信息： virsh snapshot

一、业务背景 业务需求：服务层调用多个dao方法，要求 只要有一条数据库执行语句出错，则全部回滚 。而实际情况是前面四条执行成功，第五条失败，结果只是抛出异常提示，前面四条还是成功执行。 二、出错原因 异常分为checked Exception 捕获异常 跟 unchecked Exception 未捕获异常，Spring 默认发生未捕获异常时自动回滚 ，如发生RuntimeException。项目中都有针对调用dao层方法做try-catch处理，即已经对异常做出捕获处理，不满足Spring默认自动回滚情况，所以才会出现上面所述情况。 三、解决方案（两种） 如果想要不管有没有捕获异常做处理，只要其中一条发生异常，则全部回滚，那么可以采用下面两种配置方法： 1、xml文件中进行显示配置 <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> <!-- 增加事务回滚切面扫描配置，不加的话有捕获异常就不回滚 --> <aop:config> <aop:pointcut id="serviceOperation"

再次之前自认为我对数据库事务和隔离级别很熟悉了，至少以前整理过，看过网上很多文章，有些带有命令行操作的印象挺深，但是事务传播（包块调用外部系统服务）、分布式锁、mybatis一级缓存等一起存在业务代码中，导致了很多看起来听不可思议的问题，这都是线上案例。 项目中架构师是否跟你说类似的话，事务最好不要嵌套,为什么？如果这样的话事务传播应如何使用，为了方便本片先将事务相关的基础知识做下汇总： 数据库事务ACID特性 1）原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 2）一致性（Consistency）事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 3） 隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账（其实是隔离级别中的串行化）。 4）持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 事务4种隔离级别 1):Read Uncommitted

写在前面的废话：为什么会写在第十章的后面呢？真的是尴尬……当初写完第六章那十一个设计模式之后，后面还有两个基于状态的构造技术的设计模式没有说就去吃饭了，回来忘记了嘤嘤嘤……本来想补在第六章末尾的，发现实在是太臃肿了，所以就补充到最后了。吃饭真的耽误事，下次真的不能再吃了！ 先说前面，补充的内容不多，主要是两种基于状态的设计模式――Memento（备忘录）与State 在这之前先简单的说一下什么是基于状态的编程。 基于状态编程（State-based programming）：使用有限状态机来定义程序的行为、使用状态来控制程序的执行。（喵喵？形式语言与自动机……） EG： 核心思想就是：将程序看做一个有限状态机，侧重于对“状态”及“状态转换”的抽象和编程。 在这种思想下，程序的执行被分解为一组自动执行的步骤，各步骤之间的通讯通过“状态变量”进行。程序执行就可看做是各自动步骤的不断循环，使用枚举类型enum定义状态，其可以用二维数组定义状态转换表。 好，咱们进入主要内容： 1.状态模式（State Pattern） 其分类也被规划到上一节中所提到的行为模式中。 核心思想是：考虑将来的扩展和修改，最好不用if/else结构在ADT内部实现状态转换。应该使用委派，将状态转换的行为委派到独立的state对象去完成。 类图： 当然还是栗子理解，Best理解：

Ŀ¼ 一、导语 二、Jenkins远程服务器部署、启动 三、Jenkins生产环境回滚 四、Git 分支构建 五、禅言慧语选闲 一、导语 Jenkins是什么，如何安装、配置、部署以及基本应用，已在上一篇《Jenkins安装配置，项目发布、管理详解，史上最清晰，值得收藏！》做过详细的讲解。 本文将对jenkins 的高级应用做进一步讲解。相信通过这两篇文章，大家能对jenkins有一个全面、深入的认识，并能应用于生成环境。 演示用的脚本和代码依然是从github下载： https://github.com/wzjgn/xinwei-example.git 二、Jenkins远程服务器部署、启动 jenkins自动将打包成果发送到远程服务器，并重新部署、启动服务。 jenkins支持非常灵活的配置方案，本文主要介绍种常用两种方式： Publish over SSH Post Steps 自定义shell脚本 准备工作 ssh免密配置 Jenkins所在机器通过SSH服务，将构建的代码包分发到远程服务器，并登录到远程服务器执行脚本，需要做免密配置。 本文案例通过设置SSH key免密访问远程服务器。 如有服务器A、B，现想A通过ssh免密码访问B，则将A机器中的id_rsa.pub ，拷贝到B机器的 .ssh/authorized_keys 文件中。 cat id_rsa.pub >>

https://blog.csdn.net/yalishadaa/article/details/70261973 当同一个应用程序或者不同应用程序中的多个事务在同一个数据集上并发执行时 , 可能会出现许多意外的问题 并发事务所导致的问题可以分为下面三种类型 : 对于两个事物 读取了已经被 T2 更新但还没有被提交的字段 之后 , 若 T2 回滚 ,T1 读取的内容就是临时且无效的 . 不可重复读: 对于两个事物 读取了一个字段 , 然后 T2 更新了该字段 . 之后 ,T1 再次读取同一个字段 值就不同了 . 幻读: 对于两个事物 从一个表中读取了一个字段 , 然后 T2 在该表中插入了一些新的行 . 之后 , 如果 T1 再次读取同一个表 , 就会多出几行 . 从理论上来说 事务应该彼此完全隔离 , 以避免并发事务所导致的问题 . 然而 , 那样会对性能产生极大的影响 , 因为事务必须按顺序运行 . 在实际开发中 为了提升性能 , 事务会以较低的隔离级别运行 . 事务的隔离级别可以通过隔离事务属性指定 事务的隔离级别要得到底层数据库引擎的支持 , 而不是应用程序或者框架的支持 . Oracle 支持的 2 种事务隔离级别： READ_COMMITED, SERIALIZABLE Mysql 支持 4 中事务隔离级别 . 事务的回滚通过 注解完成。 1.设置事务的隔离级别：

仔细考虑一下灰度发布系统要达到哪些目的，基本就能有答案了。需要注意的是，客户端应用（无论PC端还是移动端）的灰度发布要比Web应用的灰度发布更为复杂，因为应用运行在用户持有的终端上，数据采集和回滚都更为困难（但可采集的数据类型要更加丰富）。 注：本人缺乏移动客户端产品的经验，下述内容可能不适用于移动客户端产品。 我所理解的灰度发布系统，主要任务是从产品用户群中按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的显式反馈（论坛、微博）或隐式反馈（应用自身统计数据），对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。 从上述描述可以得出灰度发布系统需要具备的一些要素： 用户标识 用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。 目标用户选取策略 即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择