一、多个事务并发时可能遇到的问题
深入理解事务--事务ACID特性及隔离级别
ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.这是可靠数据库所应具备的几个特性.下面针对这几个特性进行逐个讲解.
理解原子性(Atomicity)
原子性意味着数据库中的事务执行是作为原子。即不可再分，整个语句要么执行，要么不执行。
在SQL SERVER中，每一个单独的语句都可以看作是默认包含在一个事务之中: 所以，每一个语句本身具有原子性，要么全部执行，这么全部不执行，不会有中间状态:上面说了，每一条T-SQL语句都可以看作是默认被包裹在一个事务之中的,SQL Server对于每一条单独的语句都实现了原子性，但这种原子粒度是非常小的，如果用户想要自己定义原子的大小，则需要包含在事务中来构成用户自定义的原子粒度:
理解一致性(Consistency)
一致性,即在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
一致性分为两个层面
1.数据库机制层面
数据库层面的一致性是，在一个事务执行之前和之后，数据会符合你设置的约束（唯一约束，外键约束,Check约束等)和触发器设置.这一点是由SQL SERVER进行保证的.
2.业务层面
对于业务层面来说,一致性是保持业务的一致性.这个业务一致性需要由开发人员进行保证.很多业务方面的一致性可以通过转移到数据库机制层面进行保证.比如，产品只有两个型号，则可以转移到使用CHECK约束使某一列必须只能存这两个型号.
比如你定义一个事务，里面的操作是A,B，C三步，系统原子性能保证的是这三步要么都执行，要么都不执行，不可拆分。但是有可能你这三部破坏了数据的一致性，比如你定义了从A账户划拨200块给B账户。如果你的事务里只包含从A账户扣款，而不包含B账户加钱。那么系统保证原子性后，能保证要么从A账户都扣款成功，要么都不成功，不会出现扣了一半款之类的异常情况。但是没办法保证B账户加钱了。所以A账户扣款，B账号加钱，这是一个连续的动作，业务逻辑上要保证一致性，所以必须把两个步骤放在一个事务里，这样才能保证一致性。
理解隔离性（Isolation)
隔离性：指的是在并发环境中，发事务之间互相影响的程度（即并发事务间数据的可见程度），当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
理解持久性（Durability)
持久性，意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
即使出现了任何事故比如断电等，事务一旦提交，则持久化保存在数据库中.
SQL SERVER通过write-ahead transaction log来保证持久性。write-ahead transaction log的意思是，事务中对数据库的改变在写入到数据库之前，首先写入到事务日志中。而事务日志是按照顺序排号的（LSN）。当数据库崩溃或者服务器断点时，重启动SQL SERVER，SQL SERVER首先会检查日志顺序号，将本应对数据库做更改而未做的部分持久化到数据库，从而保证了持久性.
多个事务并发时可能遇到的问题
Lost Update 更新丢失
- a. 第一类更新丢失，回滚覆盖：撤消一个事务时，在该事务内的写操作要回滚，把其它已提交的事务写入的数据覆盖了。
b. 第二类更新丢失，提交覆盖：提交一个事务时，写操作依赖于事务内读到的数据，读发生在其他事务提交前，写发生在其他事务提交后，把其他已提交的事务写入的数据覆盖了。这是不可重复读的特例。 - Dirty Read 脏读：一个事务读到了另一个未提交的事务写的数据。
- Non-Repeatable Read 不可重复读：一个事务中两次读同一行数据，可是这两次读到的数据不一样。
- Phantom Read 幻读：一个事务中两次查询，但第二次查询比第一次查询多了或少了几行或几列数据。
两类更新丢失的举例
第一类丢失更新(Lost Update)
时间 |
取款事务A |
存款事务B |
T1 |
开始事务 |
|
T2 |
|
开始事务 |
T3 |
查询账户余额为1000元 |
|
T4 |
|
查询账户余额为1000元 |
T5 |
|
汇入100元把余额改为1100元 |
T6 |
|
提交事务 |
T7 |
取出100元把余额改为900 元 |
|
T8 |
撤销事务 |
|
T9 |
余额恢复为1000元(丢失更新) |
|
写操作没加“持续-X锁”，没能阻止事务B写，发生了回滚覆盖。
second lost update problem 第二类丢失更新(不可重复读的特殊情况)
时间 |
取款事务A |
存款事务B |
T1 |
|
开始事务 |
T2 |
开始事务 |
|
T3 |
|
查询账户余额为1000元 |
T4 |
查询账户余额为1000元 |
|
T5 |
|
取出100元把余额改为900元 |
T6 |
|
提交事务 |
T7 |
汇入100元 |
|
T8 |
提交事务 |
|
T9 |
把余额改为1100元(丢失更新) |
|
写操作加了“持续-X锁”，读操作加了“临时-S锁”，没能阻止事务B写，发生了提交覆盖。
dirty read脏读(读到了另一个事务在处理中还未提交的数据)
时间 |
取款事务A |
存款事务B |
T1 |
开始事务 |
|
T2 |
|
开始事务 |
T3 |
|
查询账户余额为1000元 |
T4 |
|
汇入100元把余额改为1100元 |
T5 |
查询账户余额为1100元(读取脏数据) |
|
T6 |
|
回滚 |
T7 |
取款1100 |
|
T8 |
提交事务失败 |
|
non-repeatableread 不可重复读
时间 |
取款事务A |
存款事务B |
T1 |
开始事务 |
|
T2 |
|
开始事务 |
T3 |
查询账户余额为1000元 |
|
T5 |
|
汇入100元把余额改为1100元 |
T5 |
|
提交事务 |
T6 |
查询帐户余额为1100元 |
|
T8 |
提交事务 |
|
phantom read 幻读
时间 |
查询学生事务A |
插入新学生事务B |
T1 |
开始事务 |
|
T2 |
|
开始事务 |
T3 |
查询学生为10人 |
|
T4 |
|
插入1个学生 |
T5 |
查询学生为11人 |
|
T6 |
|
提交事务 |
T7 |
提交事务 |
|
二、事务隔离级别
为了解决多个事务并发会引发的问题，进行并发控制。数据库系统提供了四种事务隔离级别供用户选择。
- Read Uncommitted 读未提交：不允许第一类更新丢失。允许脏读，不隔离事务。
- Read Committed 读已提交：不允许脏读，允许不可重复读。读取已提交的数据项目中一般都使用这个，不会出现dirty read,因为只有另一个事务提交才会读出来结果，但仍然会出现 non-repeatable read 和 phantom-read。使用read-commited机制可用悲观锁乐观锁来解决non-repeatable read 和 phantom-read问题
- Repeatable Read 可重复读：不允许不可重复读。但可能出现幻读。
- Serializable 串行化：所有的增删改查串行执行。
读未提交
事务读不阻塞其他事务读和写，事务写阻塞其他事务写但不阻塞读。
可以通过写操作加“持续-X锁”实现。
读已提交
事务读不会阻塞其他事务读和写，事务写会阻塞其他事务读和写。
可以通过写操作加“持续-X”锁，读操作加“临时-S锁”实现。
可重复读
事务读会阻塞其他事务事务写但不阻塞读，事务写会阻塞其他事务读和写。
可以通过写操作加“持续-X”锁，读操作加“持续-S锁”实现。
串行化
“行级锁”做不到，需使用“表级锁”。
可串行化
如果一个并行调度的结果等价于某一个串行调度的结果，那么这个并行调度是可串行化的。
区分事务隔离级别是为了解决脏读、不可重复读和幻读三个问题的。
| 事务隔离级别 | 回滚覆盖 | 脏读 | 不可重复读 | 提交覆盖 | 幻读 |
|---|---|---|---|---|---|
| 读未提交 | x | 可能发生 | 可能发生 | 可能发生 | 可能发生 |
| 读已提交 | x | x | 可能发生 | 可能发生 | 可能发生 |
| 可重复读 | x | x | x | x | 可能发生 |
| 串行化 | x | x | x | x | x |
三、常用的解决方案
这里罗列的技术有些是数据库系统已经实现，有些需要开发者自主完成。
1. 版本检查
在数据库中保留“版本”字段，跟随数据同时读写，以此判断数据版本。版本可能是时间戳或状态字段。
下例中的 WHERE 子句就实现了简单的版本检查：
UPDATE table SET status = 1 WHERE id=1 AND status = 0;
版本检查能够作为“乐观锁”，解决更新丢失的问题。
2. 锁
2.1 共享锁与排它锁
共享锁（Shared locks, S-locks）
共享锁【S锁】
又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
排它锁（Exclusive locks, X-locks）
排他锁【X锁】
又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。
更新锁（Update locks, U-locks）
锁类型之一。引入它是因为多数数据库在实现加X锁时是执行了如下流程：先加S锁，添加成功后尝试更换为X锁。这时如果有两个事务同时加了S锁，尝试换X锁，就会发生死锁。因此增加U锁，U锁代表有更新意向，只允许有一个事务拿到U锁，该事务在发生写后U锁变X锁，未写时看做S锁。
目前好像只在 MSSQL 里看到了U锁。
2.2 临时锁与持续锁
锁的时效性。指明了加锁生效期是到当前语句结束还是当前事务结束。
2.3 表级锁与行级锁
锁的粒度。指明了加锁的对象是当前表还是当前行。
2.4 悲观锁与乐观锁
这两种锁的说法，主要是对“是否真正在数据库层面加锁”进行讨论。
悲观锁（Pessimistic Locking）
悲观锁假定当前事务操纵数据资源时，肯定还会有其他事务同时访问该数据资源，为了避免当前事务的操作受到干扰，先锁定资源。悲观锁需使用数据库的锁机制实现，如使用行级排他锁或表级排它锁。
尽管悲观锁能够防止丢失更新和不可重复读这类问题，但是它非常影响并发性能，因此应该谨慎使用。
乐观锁（Optimistic Locking）
乐观锁假定当前事务操纵数据资源时，不会有其他事务同时访问该数据资源，因此不在数据库层次上的锁定。乐观锁使用由程序逻辑控制的技术来避免可能出现的并发问题。
唯一能够同时保持高并发和高可伸缩性的方法就是使用带版本检查的乐观锁。
乐观锁不能解决脏读的问题，因此仍需要数据库至少启用“读已提交”的事务隔离级别。
3. 三级加锁协议
称之为协议，是指在使用它的时候，所有的事务都必须遵循该规则！！！
一级加锁协议
事务在修改数据前必须加X锁，直到事务结束（提交或终止）才可释放；如果仅仅是读数据，不需要加锁。
如下例：
SELECT xxx FOR UPDATE;
UPDATE xxx;
二级加锁协议
满足一级加锁协议，且事务在读取数据之前必须先加S锁，读完后即可释放S锁。
三级加锁协议
满足一级加锁协议，且事务在读取数据之前必须先加S锁，直到事务结束才释放。
4. 两段锁协议（2-phase locking）
加锁阶段：事务在读数据前加S锁，写数据前加X锁，加锁不成功则等待。
解锁阶段：一旦开始释放锁，就不允许再加锁了。
若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。
遵循两段锁协议的事务调度处理的结果是可串行化的充分条件，但是可串行化并不一定遵循两段锁协议。
两段锁协议和防止死锁的一次封锁法的异同之处
一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行，因此一次封锁法遵守两段锁协议；但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。
四、不同的事务隔离级别与其对应可选择的加锁协议
| 事务隔离级别 | 加锁协议 |
|---|---|
| 读未提交 | 一级加锁协议 |
| 读已提交 | 二级加锁协议 |
| 可重复读 | 三级加锁协议 |
| 串行化 | 两段锁协议 |
封锁协议和隔离级别并不是严格对应的。
理解“事务隔离级别-加锁的选择-三级加锁协议”之间的联系，着实花了不少功夫。