回滚

事务与并发写 某个正在更新的记录在提交或回滚前不能被其他事物同时更新 先加锁后修改 等待锁释放 事物的ACID 原子性Atomic : 要么全部执行,要么全部不执行,中途数据库发生异常,未提交的事物都被回滚 一致性Consistency : 数据库从一种正确状态转为另一种正确状态,数据库在修改时保证数据的正确性合理性一致性 隔离性Isolation 事务正确提交完成前,中间的任何数据变化对其他的事物都是不可见的 持久性Durability : 事物一旦提交就永久保存…数据库写在事务日志异步更新到磁盘,使用事务日志持久化实现只要是性能方面的考虑 四种隔离级别 1读未提交:读到未提交的数据 2读已提交:两次读取到的数据不一致(不可重复读) 3可重复读 mysql默认隔离级别 4串行化:读写数据会锁表.并发性能低 并发事务问题 脏读,读取他人未提交事物 不可重复读:其他事务对数据进行了修改 幻读:其他事务对数据进行了增加或删除 查看数据库默认的隔离级别 select @ @tx_isolation ; 默认级别可重复读 REPEATABLE - READ 设置隔离级别为–读未提交 set tx_isolation = 'read-uncommitted' ; select @ @tx_isolation ; READ - UNCOMMITTED 读已提交 --解决脏读 set tx

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 数据库的事务就是将任意多个SQL语句看做一个整体，只有这些SQL语句都成功执行，DBMS才会保存这些SQL语句对数据库的修改（事务提交）。否则，数据库将恢复到执行SQL语句之前的状态（事务回滚）。大多数DBMS都支持两种事务模式：隐式模式和显式模式。当执行每一条SQL语句时，无需进行事务提交，就可以直接将修改结果保存到数据库中，这叫做 隐式模式。显式模式必须使用相应的语句或命令开启事务、提交事务和回滚事务。 在使用JDBC时，默认情况下是 隐式事务模式，可以通过setAutoCommit方法改为显式模式。 处理步骤： 1. 开始事务： 设值属性AutoCommit为false 2.批处理SQL语句 3.提交事务conn.commit(); 4.恢复现场：AutoCommit为true。 异常时：回滚事务 如果执行SQL语句过程中 出现异常 ，则在try catch中进行处理，主要是进行事务回滚，然后恢复现场。 来源： oschina 链接： https://my.oschina.net/u/1014520/blog/225610

@Transactional 事务管理的目的 在出现异常的情况下，保证数据的一致性；数据提交操作回滚至异常发生前的状态 事务管理的方式： Spring（Spring Framework 提供对事务管理的抽象接口） 支持两种事务管理方式： 编程式事务管理：使用TransactionTemplate或PlatformTransactionManager实现 声明式事务管理：建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务（此处取决于事务的传播行为），在执行完目标方法之后根据执行情况提交或者回滚事务（执行成功则提交，失败则进行实物的回滚） 编程式事务管理优势：可以控制事务的粒度，最细粒度到代码块级别； 声明式实物管理优势：在方法外进行声明，事务控制的代码不会与业务逻辑代码混在一起，最细粒度到方法级别（解决方法：可以将需要进行事务管理的代码块独立为方法，通过方法间调用实现）；符合spring倡导的非侵入式的开发方式，即业务处理逻辑代码与事务管理代码不放在一起 声明式事务管理实现方式： 基于tx和aop名字空间的xml配置文件 // 基本配置 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns

事务概述 MySQL 事务, 主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，既需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，如果操作就必须同时操作成功，如果有一个不成功则所有数据都不动。这时候数据库操作语句就构成一个 事务 。事务主要处理数据的 增删改 操作。 定义 一件事从开始发生到结束的过程 作用 确保数据操作过程中的一致性、完整性、准确性、有效性 事务四大特性 原子性（atomicity） 一个事务必须视为一个不可分割的 最小工作单元 ，对于一个事务来说，不可能只执行其中的一部分操作,整个事务中的所有操作要么全部提交成功，要么全部失败回滚 一致性（consistency） 事务完成时，数据必须处于一致状态，数据的完整性约束没有被破坏。 隔离性（isolation） 数据库允许 多个并发事务 同时对其数据进行读写和修改的能力，而多个事务相互独立。隔离性可以防止多个事务并发执行时由于 交叉执行而导致数据的不一致 。 持久性（durability） 一旦事务提交，则其所做的修改就会 永久保存到数据库 中。此时即使系统崩溃，修改的数据也不会丢失。 事务操作 开启事务 mysql>begin; # 方法1 mysql>start transaction; # 方法2 开始执行事务中的若干条SQL命令（增删改） 终止事务

事物的简介 1.事物的概念 事物是一个操作序列，该序列中的多个操作要么都做，要么都不做 是MySQL5.5之后的存储引擎所支持 2.事物的特点 a .原子性 原子是自然界中最小的颗粒，具有不可再分的特点 事物中的所有操作可以看作是一个原子，要么全部执行，要么全不执行 b .一致性 事物执行的结果必须要保证数据库中数据的一致性 c .隔离性 隔离性指各个事物的操作是互不干扰的，任意一个事物的内部操作都对其他并发的事物都不能进行干扰 d .持久性 指事物一旦提交后，对数据库中数据做出的任何改变都会永久保存 事物的控制 1.开启事物 语法:start transaction |begin 开启一个新的事物 例如:开启新事物，完成张三给李四转账200 start transaction; update account set balance=balance-200 where username='张三'; update account set balance=balance+200 where username='李四'; 注意:使用start transaction 开启一个新事物后,该事物就不会自动提交,必须手动提交 2.提交事物 语法:commit; 例如 : 开启新事物，完成张三给李四转账 200 ，提交事物 start transaction ; update account

RC 和 RS 的功能基本上是差不多的，唯一的区别就是 RS 支持集合的 selector 。 RC|RS 是 Kubernetes 的一个核心概念，当我们把应用部署到集群之后，需要保证应用能够持续稳定的运行， RC|RS 就是这个保证的关键，主要功能如下： 确保 Pod 数量：它会确保 Kubernetes 中有指定数量的 Pod 在运行，如果少于指定数量的 Pod ， RC 就会创建新的，反之这会删除多余的，保证 Pod 的副本数量不变。 确保 Pod 健康：当 Pod 不健康，比如运行出错了，总之无法提供正常服务时， RC 也会杀死不健康的 Pod ，重新创建新的。 弹性伸缩：在业务高峰或者低峰的时候，可以用过 RC 来动态的调整 Pod 数量来提供资源的利用率，当然我们也提到过如果使用 HPA 这种资源对象的话可以做到自动伸缩。 滚动升级：滚动升级是一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定性。 Deployment 同样也是 Kubernetes 系统的一个核心概念，主要职责和 RC|RS 一样的都是保证 Pod 的数量和健康，二者大部分功能都是完全一致的，我们可以看成是一个升级版的 RC|RS 控制器，那 Deployment 又具备那些新特性呢？ RC|RS 的全部功能： Deployment 具备上面描述的 RC|RS 的全部功能 事件和状态查看

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。 ACID 指数据库事务正确执行的四个基本要素： 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） CAP CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性 ：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 可用性 ：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 分区容忍性 ：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 BASE理论 BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是： 我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。 Basically Available（基本可用） Soft state（软状态） Eventually consistent（最终一致性）

锁 数据库系统使用锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性。 InnoDB存储引擎中的锁 共享锁（S Lock），允许事务读一行数据 排他锁（X Lock），允许事务删除或更新一行数据 兼容性： S与S可以兼容 X不与任何锁兼容 InnoDB支持多粒度锁定，也就是允许行级和表级的锁同时存在。实现方式为通过意向锁（Intention Lock）：如果需要对最细粒度进行加锁，需要在上层粒度加意向锁。 具体举例，如果需要对行加X锁，需要对表、页依次加IX锁。当意向锁遇到等待时，必须等待结束后才能继续对下级加锁。如准备加对一行有S锁的行加S锁，行记录因为原来就有S锁，所以表和页都已经存在了IS锁，首先新的IS锁加在表上，因为IS、IS锁兼容，可以加上；然后再看页锁，同样IS、IS兼容，可以加上；最后看行锁IS与S兼容，那么行记录可以加上S锁。对同样这行有S锁的行加X锁，先加表IX锁，IX与IS兼容，可以加上，页同样，最后IX锁与行记录上的S锁不兼容，因此要等待S锁释放后才能加上X锁。 一致性非锁定读 一致性非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi version）的方式来读取当前执行时间数据库中行的数据。在行记录正在执行DELETE或UPDATE时执行读操作，不会等待锁释放

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 从功能上划分，SQL 语言可以分为DDL,DML和DCL三大类。 1. DDL（Data Definition Language） 数据定义语言，用于定义和管理 SQL 数据库中的所有对象的语言 ； CREATE---创建表 ALTER---修改表 DROP---删除表 2. DML（Data Manipulation Language） 数据操纵语言，SQL中处理数据等操作统称为数据操纵语言 ； INSERT---数据的插入 DELETE---数据的删除 UPDATE---数据的修改 SELECT---数据的查询 3. DCL（Data Control Language） 数据控制语言，用来授予或回收访问数据库的某种特权，并控制 数据库操纵事务发生的时间及效果，对数据库实行监视等； GRANT--- 授权。 ROLLBACK---回滚。 COMMIT--- 提交。 4. 提交数据有三种类型：显式提交、隐式提交及自动提交。 下面分 别说明这三种类型。 (1) 显式提交 用 COMMIT 命令直接完成的提交为显式提交。 (2) 隐式提交 用 SQL 命令间接完成的提交为隐式提交。这些命令是： ALTER ， AUDIT ， COMMENT ， CONNECT ， CREATE ， DISCONNECT ，

shutdown normal 不断开现在连接的用户,阻止任何用户建立新的连接，包括管理员在内。已经连接的用户能够继续他们当前的工作,如递交新的更新事务,直到此用户自行断开连接.这样需要等待的时间长,可以查出现连用户,再通知其自行断开. 所有的用户都断开连接，数据库才进行关闭操作，即关闭数据库、卸载数据库、终止例程。在这种情况下关闭的数据库在重新启动后，不会出现问题。启动时不需要实例恢复。 shutdown transactional 阻止任何用户建立新的连接。等待所有当前连接用户的未递交的活动事务提交完毕，然后立即断开用户的连接。所有的用户都断开连接则立即关闭数据库，进行关闭数据库、卸载数据库、终止进程等操作。这种方式,用户有可能正在算账,做复杂报表!一次数据库操作做不完的,在刚做了一次数据库操作后,将被断开,这样对用户有一定影响.启动时不需要实例恢复。 shutdown immediate 阻止任何用户新的连接，同时限制当前连接用户开始新的事务。如果已连接用户有未完成的事务，则数据库系统不会等待他们完成，而是直接把当前未递交的事务回退。数据库系统不再等待用户主动断开连接，当未递交的事务回退成功后，系统会直接关闭、卸载数据库，并终止数据库进程。启动时不需要实例恢复。 shutdown abort 当数据库出现故障时，可能以上三种方式都无法正常关闭数据库,则使用这种方法