事务并发的可能问题与其解决方案
一、多个事务并发时可能遇到的问题
- Lost Update 更新丢失
a. 第一类更新丢失，回滚覆盖：撤消一个事务时，在该事务内的写操作要回滚，把其它已提交的事务写入的数据覆盖了。
b. 第二类更新丢失，提交覆盖：提交一个事务时，写操作依赖于事务内读到的数据，读发生在其他事务提交前，写发生在其他事务提交后，把其他已提交的事务写入的数据覆盖了。这是不可重复读的特例。 - Dirty Read 脏读：一个事务读到了另一个未提交的事务写的数据。
- Non-Repeatable Read 不可重复读：一个事务中两次读同一行数据，可是这两次读到的数据不一样。
- Phantom Read 幻读：一个事务中两次查询，但第二次查询比第一次查询多了或少了几行或几列数据。
两类更新丢失的举例
| 时间 | 取款事务A | 转账事务B |
|---|---|---|
| T1 | 开始事务 | |
| T2 | 开始事务 | |
| T3 | 读余额为1000 | |
| T4 | 取出100，余额改为900 | - |
| T5 | 读余额为1000 | |
| T6 | 汇入100，余额改为1100 | |
| T7 | 提交事务，余额定为1100 | |
| T8 | 撤销事务，余额改回1000 | - |
| T9 | 最终余额1000，更新丢失 | - |
写操作没加“持续-X锁”，没能阻止事务B写，发生了回滚覆盖。
| 时间 | 转账事务A | 取款事务B |
|---|---|---|
| T1 | 开始事务 | |
| T2 | 开始事务 | |
| T3 | 读余额为1000 | |
| T4 | 读余额为1000 | |
| T5 | 取出100，余额改为900 | |
| T6 | 提交事务，余额定为900 | |
| T7 | 汇入100，余额改为1100 | - |
| T8 | 提交事务，余额定为1100 | - |
| T9 | 最终余额1100，更新丢失 | - |
写操作加了“持续-X锁”，读操作加了“临时-S锁”，没能阻止事务B写，发生了提交覆盖。
二、事务隔离级别
为了解决多个事务并发会引发的问题，进行并发控制。数据库系统提供了四种事务隔离级别供用户选择。
- Read Uncommitted 读未提交：不允许第一类更新丢失。允许脏读，不隔离事务。
- Read Committed 读已提交：不允许脏读，允许不可重复读。
- 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锁的对象添加S锁。对象可以接受添加多把S锁。
排它锁（Exclusive locks, X-locks）
基本锁类型之一。加排它锁的对象只允许被当前事务读和写。也称独占锁，写锁。
只能给未加锁的对象添加X锁。对象只能接受一把X锁。加X锁的对象不能再加任何锁。
更新锁（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锁，加锁不成功则等待。
解锁阶段：一旦开始释放锁，就不允许再加锁了。
若并发执行的所有事务均遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的。
遵循两段锁协议的事务调度处理的结果是可串行化的充分条件，但是可串行化并不一定遵循两段锁协议。
两段锁协议和防止死锁的一次封锁法的异同之处
一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行，因此一次封锁法遵守两段锁协议；但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。
四、不同的事务隔离级别与其对应可选择的加锁协议
| 事务隔离级别 | 加锁协议 |
|---|---|
| 读未提交 | 一级加锁协议 |
| 读已提交 | 二级加锁协议 |
| 可重复读 | 三级加锁协议 |
| 串行化 | 两段锁协议 |
封锁协议和隔离级别并不是严格对应的。
理解“事务隔离级别-加锁的选择-三级加锁协议”之间的联系，着实花了不少功夫。
