事务隔离级别

所谓的数据库事务操作其实就是一组原子性的操作，要么全部操作成功，要么全部操作失败。 并行事务的四大问题： 1.更新丢失：和别的事务读到相同的东西，各自写，自己的写被覆盖了。（谁写的快谁的更新就丢失了） 2.脏读：读到别的事务未提交的数据。（万一回滚，数据就是脏的无效的了） 3.不可重复读：两次读之间有别的事务修改。 4.幻读：两次读之间有别的事务增删。 对应隔离级别 1.READ UNCOMMITTED：读未提交，不处理。 2.READ COMMITTED：读已提交，只读提交的数据，无脏读； 3.REPEATABLE READ：可重复读，加行锁，两次读之间不会有修改，无脏读无重复读； 4.SERIALIZABLE: 串行化，加表锁，全部串行，无所有问题。 　　1.READ UNCIMMITTED（未提交读） 　　 事务还没提交，而别的事务可以看到他其中修改的数据的后果，也就是脏读。 　　2.READ COMMITTED（提交读） 　　 首先大多数数据库系统的默认隔离级别是READ COMMITTED，这种隔离级别就是一个事务的开始，只能看到已经完成的事务的结果，正在执行的，是无法被其他事务看到的。这种级别会出现读取旧数据的现象 　　3.REPEATABLE READ（可重复读） 　　 REPEATABLE READ解决了脏读的问题，该级别保证了每行的记录的结果是一致的

数据库基本知识点梳理系列 - 锁 数据库的锁是用于保证数据库事务在并发的情况下依旧能够保证数据的一致性的. 所以深入理解锁的原理, 能够帮助我们更好地理解事务隔离级别的原理, 以及在实际的业务场景中, 有把握的使用隔离级别保障系统的效率和稳定. 锁的分级 级别 加锁速度以及开销 是否会出现死锁的情况 粒度 并发事务的性能影响 表级锁 快, 开销小 不会出现死锁 锁定粒度很大, 因此发生加锁的冲突概率最高 并发度最低 行级锁 开销大, 加锁慢 会出现死锁 锁定粒度最小, 发生加锁冲突概率最低 并发度最高 页面锁 开销和加速速度介于上面两者间 会出现死锁 粒度介于上面两者之间 并发度介于两者之间 行级锁 锁名称 代号 描述 共享锁 （S） 读锁 。可以并发读取数据，但不能修改数据。也就是说当数据资源上存在共享锁的时候，所有的事务都不能对这个资源进行修改，直到数据被所有资源读取完成，共享锁释放。 排它锁 （X） 独占锁、 写锁 。就是如果你对数据资源进行增删改(DML)操作时，不允许其它任何事务操作这块资源，直到排它锁被释放，防止同时对同一资源进行多重操作。当资源上已经有共享锁或者排他锁, 则无法对这个资源添加额外的排他锁. 即排他锁与共享锁不兼容. 排他锁与自己也不兼容. 更新锁 （U） 当事务发现资源上既没有更新锁也没有排他锁时, 可以对资源添加更新锁, 也就是说,

数据库锁知识 不少人在开发的时候，应该很少会注意到这些锁的问题，也很少会给程序加锁(除了库存这些对数量准确性要求极高的情况下)，即使我们不会这些锁知识，我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库隐式帮我们加了，只会在某些特定的场景下才需要手动加锁。 对于UPDATE、DELETE、INSERT语句，InnoDB会自动给涉及数据集加排他锁（X) MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁，在执行增、删、改操作前，会自动给涉及的表加写锁，这个过程并不需要用户干预 表锁 首先，从锁的粒度，我们可以分成两大类： 表锁 :开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低 行锁:开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高 不同的存储引擎支持的锁粒度是不一样的==：InnoDB行锁和表锁都支持、MyISAM只支持表锁！InnoDB只有通过索引条件检索数据才使用行级锁==，否则，InnoDB使用表锁也就是说，InnoDB的行锁是基于索引的！ 表锁下又分为两种模式： 表读锁（Table Read Lock）&& 表写锁（Table Write Lock） 从下图可以清晰看到，在表读锁和表写锁的环境下：读读不阻塞，读写阻塞，写写阻塞！读读不阻塞：当前用户在读数据，其他的用户也在读数据，不会加锁 读写阻塞

1. 事务的基本介绍 1. 概念： * 如果一个包含多个步骤的业务操作，被事务管理，那么这些操作要么同时成功，要么同时失败。 2. 操作： 1. 开启事务： start transaction; 2. 回滚：rollback; 3. 提交：commit; 3. 例子： CREATE TABLE account ( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR(10), balance DOUBLE ); -- 添加数据 INSERT INTO account (NAME, balance) VALUES ('zhangsan', 1000), ('lisi', 1000); SELECT * FROM account; UPDATE account SET balance = 1000; -- 张三给李四转账 500 元 -- 0. 开启事务 START TRANSACTION; -- 1. 张三账户 -500 UPDATE account SET balance = balance - 500 WHERE NAME = 'zhangsan'; -- 2. 李四账户 +500 -- 出错了... UPDATE account SET balance = balance + 500 WHERE NAME = 'lisi'; --

一、MySQL架构 第一层，即最上一层 ，所包含的服务并不是MySQL所独有的技术。它们都是服务于C/S程序或者是这些程序所需要的 ：连接处理，身份验证，安全性等等。 第二层值得关注 。这是MySQL的核心部分。通常叫做 SQL Layer。在 MySQL据库系统处理底层数据之前的所有工作都是在这一层完成的，包括权限判断， sql解析，行计划优化， query cache 的处理以及所有内置的函数(如日期,时间,数学运算,加密)等等。各个存储引擎提供的功能都集中在这一层，如存储过程，触发器，视 图等。 第三层包括了存储引擎 。通常叫做StorEngine Layer ，也就是底层数据存取操作实现部分，由多种存储引擎共同组成。它们负责存储和获取所有存储在MySQL中的数据。就像Linux众多的文件系统 一样。每个存储引擎都有自己的优点和缺陷。服务器是通过存储引擎API来与它们交互的。这个接口隐藏 了各个存储引擎不同的地方。对于查询层尽可能的透明。这个API包含了很多底层的操作。如开始一个事 物，或者取出有特定主键的行。存储引擎不能解析SQL，互相之间也不能通信。仅仅是简单的响应服务器 的请求。 连接管理和安全 在服务器内部，每个client连接都有自己的线程。这个连接的查询都在一个单独的线程中执行。这些线程轮流运行在某一个CPU内核(多核CPU)或者CPU中。服务器缓存了线程

写在前面的话 本文所有Kafka原理性的描述除特殊说明外均基于Kafka 1.0.0版本。 为什么要提供事务机制 Kafka事务机制的实现主要是为了支持 Exactly Once 即正好一次语义 操作的原子性 有状态操作的可恢复性 Exactly Once 《 Kafka背景及架构介绍 》一文中有说明Kafka在0.11.0.0之前的版本中只支持 At Least Once 和 At Most Once 语义，尚不支持 Exactly Once 语义。 但是在很多要求严格的场景下，如使用Kafka处理交易数据， Exactly Once 语义是必须的。我们可以通过让下游系统具有幂等性来配合Kafka的 At Least Once 语义来间接实现 Exactly Once 。但是： 该方案要求下游系统支持幂等操作，限制了Kafka的适用场景 实现门槛相对较高，需要用户对Kafka的工作机制非常了解 对于Kafka Stream而言，Kafka本身即是自己的下游系统，但Kafka在0.11.0.0版本之前不具有幂等发送能力 因此，Kafka本身对 Exactly Once 语义的支持就非常必要。 操作原子性 操作的原子性是指，多个操作要么全部成功要么全部失败，不存在部分成功部分失败的可能。 实现原子性操作的意义在于： 操作结果更可控，有助于提升数据一致性 便于故障恢复。因为操作是原子的

#死锁分析与解决 ##事务并发执行 ##事务持锁 MySQL数据库是以行加锁的方式，避免不同事务，对同一行数据库进行同时修改的。首先来看事务一，对张三这条记录的Account字段进行修改，需要持有张三这条数据库的行锁。然后事务二也同时并发执行，事务二首先修改李四这条数据库记录的Corp字段，持有李四这条数据库的行锁。 此时两个事务各持有一个行锁，但是接下来事务一要持有事务二的行锁，事务二要持有事务一的行锁。这样就形成了事务一与事务二相互等待，导致两个事务都无法继续执行下去。 ##死锁 死锁 ：指 两个 或者 两个以上 的事务，在执行过程中，因 争夺锁资源 而造成的一种 互相等待 的现象。 死锁必须是两个或者两个以上的事务，单个事务不可能发生死锁。死锁是因为争夺锁资源，导致相互持有锁资源，导致相互等待。需要外部干涉的现象。 ##死锁产生的必要条件 互斥 并发执行的事务为了进行必要的隔离保证执行正确，在事务结束前，需要对修改的数据库记录持锁，保证多个事务对相同数据库记录串行修改 对于大型并发系统无法避免 请求与保持 一个事务申请多个资源，已经持有一个资源锁，等待另外一个资源锁 死锁仅发生在请求两个或者两个以上的锁对象 由于应用实际需要，难以消除 不剥夺 已经获得锁资源的事务，在未执行前，不能被强制剥夺，只能使用完时，由事务自己释放。 一般用于已经出现死锁时

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd"> <!--配置业务层--> <bean

ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性） 事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的。MySQL 是一个支持多引擎的系统，但并不是所有的引擎都支持事务， MyISAM 引擎就不支持事务。 当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题。 隔离级别 　　隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。 读未提交（read uncommitted）：一个事务还没提交时，它做的变更就能被别的事务看到。 读提交（read committed）：一个事务提交之后，它做的变更才会被其他事务看到。 可重复读（repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。 串行化（serializable ）：串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 　　 　　 　　1. 若隔离级别是

数据库事务(Database Transaction)： 是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 简单的说：事务就是将一堆SQL(通常是增删改操作)的执行绑在一起，要么都执行成功，要么都执行失败，即都执行成功才算成功，否则就会恢复到这堆SQL执行之前的状态。 事务的四大特性(ACID): (1) 原子性 （Atomicity）：事务中所有操作是不可再分割的原子单位。事务中所有操作要么全部执行成功，要么全部执行失败。 (2) 一致性 （Consistency）：事务执行后，数据库状态与其它业务规则保持一致。如转账业务，无论事务执行成功与否，参与转账的两个账号金额之和应该是不变的。 (3) 隔离性 （Isolation）：隔离性是指在并发操作中，不同事务之间应该隔离开来，使每个并发中的事务不会相互干扰。也就是说，在事中务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据. (4) 持久性 （Durability）：一旦事务提交成功，事务中所有的数据操作都必须被持久化到数据库中，即使提交事务后，数据库马上崩溃，在数据库重启时，也必须能保证通过某种机制恢复数据。 MySQL中的事务: 开启事务：start transaction； 结束事务：commit（提交事务