回滚

分布式事务了解吗？如果解决分布式事务问题的？ 面试官心里： 只要聊到你做了分布式系统，必问分布式事务，起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 为什么要有分布式事务？ 分布式事务实现的几种方案： 1. 两阶段提交方案/XA 方案 这种分布式事务方案，比较适合单块应用里。 跨多个库的分布式事务 ，由于因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。 如果要玩儿，那么基于 Spring + JTA 就可以搞定。 这个方案，很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。 如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。 2. TCC(Try, Confirm, Cancel) 方案 使用补偿机制。分三个阶段： Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。 Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。 Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚） 缺点：与业务耦合太紧，事务回滚严重依赖自己的写的代码来回滚和补偿。 适用场景： 与钱打交道的场景，支付，交易 。需要TCC，严格保证分布式事务要么全部成功

delete删除的时候可以配合事务，将删除掉的数据找回，回滚roolback，还可以加where删除条件，只删除数据，表结构还在 truncate不跟删除条件，不可回滚，删除所有的数据和表结构，自增id会重置 drop不跟删除条件，不可回滚，删除所有的数据和表结构，重新复制一张新的表结构，自增id不重置 来源： CSDN 作者： CoralJIao 链接： https://blog.csdn.net/Cjiaocsda1127/article/details/103465338

在有关微服务、DevOps、Cloud-native、系统部署等的讨论中，蓝绿部署、A/B 测试、灰度发布、滚动发布、红黑部署等概念经常被提到，它们有什么区别呢？通过搜索相关资料，做一个简单的辨析，如下： 一、蓝绿部署（Blue/Green Deployme nt） 过去的 10 年里，很多公司都在使用蓝绿部署（发布）来实现热部署，这种部署方式具有安全、可靠的特点。蓝绿部署虽然算不上“ Sliver Bullet”，但确实很实用。 蓝绿部署是最常见的一种0 downtime部署的方式，是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。蓝绿部署原理上很简单，就是通过冗余来解决问题。通常生产环境需要两组配置（蓝绿配置），一组是active的生产环境的配置（绿配置），一组是inactive的配置（蓝绿配置）。用户访问的时候，只会让用户访问active的服务器集群。在绿色环境（active）运行当前生产环境中的应用，也就是旧版本应用version1。当你想要升级到version2 ，在蓝色环境（inactive）中进行操作，即部署新版本应用，并进行测试。如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝色环境了。随后需要监测新版本应用，也就是version2 是否有故障和异常。如果运行良好，就可以删除version1 使用的资源。如果运行出现了问题

银行转账案例分析 在更新转入账户和转出账户时，中间加上这句： 造成：虽然报错，但是数据库更新了部分数据 再来看看QueryRunner的配置： <!--配置QueryRunner--> <bean id="runner" class="org.apache.commons.dbutils.QueryRunner" scope="prototype"> <!--注入数据源--> <constructor-arg name="ds" ref="dataSource"></constructor-arg> </bean> 可以看到，每一次与数据库进行交互，都会产生一个Runner. 一个函数里面所有的操作，都应该由一个Connection来操作: 解决方法：让业务层实现业务的回滚 定义Utils.ConnectionUtils.java，连接的工具类，用于从数据源中获取一个链接，并且实现和线程的绑定: public Connection getThreadConnection(){ //1、先从ThreadLocal上获取 Connection conn = tl.get(); //2、判断当前线程上是否有链接 if(conn == null){ //从数据源中获取一个链接，和线程绑定，存入ThreadLocal中 conn = datasource.getConnection();

文章目录 1.【基本配置】 2.【仓库操作】 3.【差异比较】 4.【查看日志】 5.【文件操作】 6.【文件回滚】 7.【分支操作】 8.【代码合并】 9.【冲突处理】 10.【子模块】 11.【储藏操作（stashing）】 12.【LFS（Large File Storage）】 1.【基本配置】 设置用户名：git config --global user.name 设置邮箱：git config --global user.email 永久保存帐号密码：git config --global credential.helper store 临时保存帐号密码：git config --global credential.helper cache 查看所有配置：git config --list 删除配置：git config --global —unset 配置代理：git config [–global] http.proxy|https.proxy （不加—global时只对当前repo生效） 2.【仓库操作】 检出仓库：git clone 同步远端仓库并merge：git pull [remote] [local] 同步远端仓库并rebase：git pull -r [remote] [local] 查看远端仓库：git remote -v 添加远端仓库：git

本文转载自： 这位阿里的面试官别走，我这有一份祖传的Mybatis面试题送给你 想学Mybatis嘛？我教你呀！ 1. 精讲#{}和${}的区别是什么？ mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值。 mybatis在处理 时 ， 就 是 把 {}时，就是把 时 ， 就 是 把 {}替换成变量的值。 使用#{}可以有效的防止SQL注入，提高系统安全性。原因在于：预编译机制。 预编译完成之后，SQL的结构已经固定，即便用户输入非法参数，也不会对SQL的结构产生影响，从而避免了潜在的安全风险 。 预编译是提前对SQL语句进行预编译，而其后注入的参数将不会再进行SQL编译。我们知道，SQL注入是发生在编译的过程中，因为恶意注入了某些特殊字符，最后被编译成了恶意的执行操作。而预编译机制则可以很好的防止SQL注入。 既然 KaTeX parse error: Expected 'EOF', got '#' at position 17: …}会引起sql注入，为什么有了#̲{}还需要有 {}呢？那其存在的意义是什么？ #{} 主要用于预编译，而预编译的场景其实非常受限，而${}用于替换，很多场景会出现替换，而这种场景可不是预编译 2. 数据库链接中断如何处理 数据库的访问底层是通过tcp实现的

在分布式系统中，同时满足“一致性”、“可用性”和“分区容错性”三者是不可能的。分布式系统的事务一致性是一个技术难题，各种解决方案孰优孰劣？老司机介绍 丁浪，现就职于某垂直电商平台，担任技术架构师。关注高并发、高可用的架构设计，对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。 在OLTP系统领域，我们在很多业务场景下都会面临事务一致性方面的需求，例如最经典的Bob给Smith转账的案例。传统的企业开发，系统往往是以单体应用形式存在的，也没有横跨多个数据库。 我们通常只需借助开发平台中特有数据访问技术和框架（例如Spring、JDBC、ADO.NET），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库通常具有ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 而大型互联网平台往往是由一系列分布式系统构成的，开发语言平台和技术栈也相对比较杂，尤其是在SOA和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多。单一的技术手段和解决方案，已经无法应对和满足这些复杂的场景了。 分布式系统的特性 对分布式系统有过研究的读者，可能听说过“CAP定律”、“Base理论”等，非常巧的是

原文链接： https://blog.ouyangsihai.cn/ >> MySQL事务，这篇文章就够了 在看这篇文章之前，我们回顾一下前面的几篇关于MySQL的系列文章，应该对你读下面的文章有所帮助。 InnoDB与MyISAM等存储引擎对比 面试官问你B树和B+树，就把这篇文章丢给他 MySQL的B+树索引的概念、使用、优化及使用场景 MySQL全文索引最强教程 MySQL的又一神器-锁，MySQL面试必备 0 什么是事务 事务（Transaction） 是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都 执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每 个事务结束时，都能保持数据一致性。 同时，事务有着严格的地定义，必须满足四个特性，也就是我们一直说的ACID，但是，并不是说各种数据库就一定会满足四个特性，对于不同的数据库的实现来说，在不同程度上是不一定完全满足要求的，比如，Oracle数据库来说，默认的事务隔离级别是 READ COMMITTED ，是不满足隔离性的要求的。 下面我们趁热打铁，介绍一下事务的必知必会的四大特性，这几个特性也是在面试中，面试官面试MySQL的相关知识的时候，问的比较多的问题，所以，这几个特性务必需要理解并且透彻的记在心里，开个玩笑，被火车撞了，也不应该忘记这四个特性！ 1 事务的四大特性

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 这一几天一直在回顾事务相关的知识，也准备把以前了解皮毛的知识进行一些深入总结，虽然这一些知识并没有用到，但是了解其实现原理还是很有必要的，因为知道了原理，你也能把它实现出来。 在上一节事务的编程模型里面，主要说明了三种编程模型，一般情况下，我们都接触的是单一资源的事务，也就是单独对一个数据库进行操作。如果需要跨多个资源保证事务一致性 举个例子：在ATM机取钱的时候，需要对用户的账户进行扣款处理，然后发送一条消息给消息服务器（假设消息服务器是用JMS实现的），由消息服务器异步通过短信通知用户。如果用户取款失败，那么消息服务器不应该发送短信给用户。如何保证 用户帐务扣款 和 消息服务器的消息保持一致性，也就是说 取款成功，消息服务器就持久化消息，然后发送短信给用户，取款失败，消息服务器就回滚消息，啥都不做。 在上面这种情况下，就需要使用分布式事务，也就是跨越多个资源的保证数据一致性。 X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由这个厂商进行具体的实现。这个思想在java 平台里面到处都是。 X/Open DTP 定义了三个组件： AP

git的工作流 工作区：即自己当前分支所修改的代码，git add xx 之前的！不包括 git add xx 和 git commit xxx 之后的。 暂存区：已经 git add xxx 进去，且未 git commit xxx 的。 本地分支：已经git commit -m xxx 提交到本地分支的。 远程分支：git push到的地方 代码回滚 在上传代码到远程仓库的时候，不免会出现问题，任何过程都有可能要回滚代码： 1、在工作区的代码 git checkout – a.txt # 丢弃某个文件，或者 git checkout – . # 丢弃全部 注意：git checkout – . 丢弃全部，也包括：新增的文件会被删除、删除的文件会恢复回来、修改的文件会回去。这几个前提都说的是，回到暂存区之前的样子。对之前保存在暂存区里的代码不会有任何影响。对commit提交到本地分支的代码就更没影响了。当然，如果你之前压根都没有暂存或commit，那就是回到你上次pull下来的样子了。 2、代码git add到缓存区，并未commit提交 git reset HEAD . 或者 git reset HEAD a.txt 这个命令仅改变暂存区，并不改变工作区，这意味着在无任何其他操作的情况下，工作区中的实际文件同该命令运行之前无任何变化 3、git commit到本地分支