事务并发的可能问题与其解决方案

一、多个事务并发时可能遇到的问题

  1. Lost Update 更新丢失
    a. 第一类更新丢失,回滚覆盖:撤消一个事务时,在该事务内的写操作要回滚,把其它已提交的事务写入的数据覆盖了。
    b. 第二类更新丢失,提交覆盖:提交一个事务时,写操作依赖于事务内读到的数据,读发生在其他事务提交前,写发生在其他事务提交后,把其他已提交的事务写入的数据覆盖了。这是不可重复读的特例。
  2. Dirty Read 脏读:一个事务读到了另一个未提交的事务写的数据。
  3. Non-Repeatable Read 不可重复读:一个事务中两次读同一行数据,可是这两次读到的数据不一样。
  4. 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可能发生可能发生可能发生可能发生
读已提交xx可能发生可能发生可能发生
可重复读xxxx可能发生
串行化xxxxx

三、常用的解决方案

这里罗列的技术有些是数据库系统已经实现,有些需要开发者自主完成。

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 表级锁与行级锁

锁的粒度。指明了加锁的对象是当前表还是当前行。

在这里学习 MSSQL 的“锁粒度和层次结构”

2.4 悲观锁与乐观锁

这两种锁的说法,主要是对“是否真正在数据库层面加锁”进行讨论。

悲观锁(Pessimistic Locking)

悲观锁假定当前事务操纵数据资源时,肯定还会有其他事务同时访问该数据资源,为了避免当前事务的操作受到干扰,先锁定资源。悲观锁需使用数据库的锁机制实现,如使用行级排他锁或表级排它锁。

尽管悲观锁能够防止丢失更新和不可重复读这类问题,但是它非常影响并发性能,因此应该谨慎使用。

乐观锁(Optimistic Locking)

乐观锁假定当前事务操纵数据资源时,不会有其他事务同时访问该数据资源,因此不在数据库层次上的锁定。乐观锁使用由程序逻辑控制的技术来避免可能出现的并发问题。

唯一能够同时保持高并发和高可伸缩性的方法就是使用带版本检查的乐观锁。

乐观锁不能解决脏读的问题,因此仍需要数据库至少启用“读已提交”的事务隔离级别。

3. 三级加锁协议

称之为协议,是指在使用它的时候,所有的事务都必须遵循该规则!!!

一级加锁协议

事务在修改数据前必须加X锁,直到事务结束(提交或终止)才可释放;如果仅仅是读数据,不需要加锁。

如下例:

SELECT xxx FOR UPDATE;
UPDATE xxx;
二级加锁协议

满足一级加锁协议,且事务在读取数据之前必须先加S锁,读完后即可释放S锁。

三级加锁协议

满足一级加锁协议,且事务在读取数据之前必须先加S锁,直到事务结束才释放。

4. 两段锁协议(2-phase locking)

加锁阶段:事务在读数据前加S锁,写数据前加X锁,加锁不成功则等待。
解锁阶段:一旦开始释放锁,就不允许再加锁了。

若并发执行的所有事务均遵守两段锁协议,则对这些事务的任何并发调度策略都是可串行化的。
遵循两段锁协议的事务调度处理的结果是可串行化的充分条件,但是可串行化并不一定遵循两段锁协议。

两段锁协议和防止死锁的一次封锁法的异同之处

一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行,因此一次封锁法遵守两段锁协议;但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁,因此遵守两段锁协议的事务可能发生死锁。

四、不同的事务隔离级别与其对应可选择的加锁协议

事务隔离级别加锁协议
读未提交一级加锁协议
读已提交二级加锁协议
可重复读三级加锁协议
串行化两段锁协议

封锁协议和隔离级别并不是严格对应的。

理解“事务隔离级别-加锁的选择-三级加锁协议”之间的联系,着实花了不少功夫。

 

来源: https://www.jianshu.com/p/71a79d838443

-----------------------

数据库的事务并发、事务隔离级别

原创罗拙呓 发布于2015-07-21 15:07:12 阅读数 525 收藏
展开

最近在做数据库有关的部分时候设计到了事务,对此重新梳理了一遍:

并发问题可归纳为以下几类:

A.丢失更新:撤销一个事务时,把其他事务已提交的更新数据覆盖(A和B事务并发执行,A事务执行更新后,提交;B事务在A事务更新后,B事务结束前也做了对该行数据的更新操作,然后回滚,则两次更新操作都丢失了)。

B.脏读:一个事务读到另一个事务未提交的更新数据(A和B事务并发执行,B事务执行更新后,A事务查询B事务没有提交的数据,B事务回滚,则A事务得到的数据不是数据库中的真实数据。也就是脏数据,即和数据库中不一致的数据)。

C.不可重复读:一个事务读到另一个事务已提交的更新数据(A和B事务并发执行,A事务查询数据,然后B事务更新该数据,A再次查询该数据时,发现该数据变化了)。

D. 覆盖更新:这是不可重复读中的特例,一个事务覆盖另一个事务已提交的更新数据(即A事务更新数据,然后B事务更新该数据,A事务查询发现自己更新的数据变了)。

E.虚读(幻读):一个事务读到另一个事务已提交的新插入的数据(A和B事务并发执行,A事务查询数据,B事务插入或者删除数据,A事务再次查询发现结果集中有以前没有的数据或者以前有的数据消失了)。

数据库系统提供了四种事务隔离级别供用户选择:

A.Serializable(串行化):一个事务在执行过程中完全看不到其他事务对数据库所做的更新(事务执行的时候不允许别的事务并发执行。事务串行化执行,事务只能一个接着一个地执行,而不能并发执行。)。

B.Repeatable Read(可重复读):一个事务在执行过程中可以看到其他事务已经提交的新插入的记录,但是不能看到其他其他事务对已有记录的更新。

C.Read Commited(读已提交数据):一个事务在执行过程中可以看到其他事务已经提交的新插入的记录,而且能看到其他事务已经提交的对已有记录的更新。

D.Read Uncommitted(读未提交数据):一个事务在执行过程中可以看到其他事务没有提交的新插入的记录,而且能看到其他事务没有提交的对已有记录的更新。

丢失更新 脏读 非重复读 覆盖更新 幻像读 未提交读

串行化 Y Y Y Y Y

已提交读 N N Y Y Y

可重复读 N N N N Y

串行化 N N N N N

数据库系统有四个隔离级别(大多数数据库默认级别为read commited)。对数据库使用何种隔离级别要审慎分析,因为
1. 维护一个最高的隔离级别虽然会防止数据的出错,但是却导致了并行度的损失,以及导致死锁出现的可能性增加。
2. 然而,降低隔离级别,却会引起一些难以发现的bug。

SERIALIZABLE(序列化)

添加范围锁(比如表锁,页锁等,关于range lock,我也没有很深入的研究),直到transaction A结束。以此阻止其它transaction B对此范围内的insert,update等操作。

幻读,脏读,不可重复读等问题都不会发生。

REPEATABLE READ(可重复读)

对于读出的记录,添加共享锁直到transaction A结束。其它transaction B对这个记录的试图修改会一直等待直到transaction A结束。

可能发生的问题:当执行一个范围查询时,可能会发生幻读。

READ COMMITTED(提交读)

在transaction A中读取数据时对记录添加共享锁,但读取结束立即释放。其它transaction B对这个记录的试图修改会一直等待直到A中的读取过程结束,而不需要整个transaction A的结束。所以,在transaction A的不同阶段对同一记录的读取结果可能是不同的。

可能发生的问题:不可重复读。

READ UNCOMMITTED(未提交读)

不添加共享锁。所以其它transaction B可以在transaction A对记录的读取过程中修改同一记录,可能会导致A读取的数据是一个被破坏的或者说不完整不正确的数据。

另外,在transaction A中可以读取到transaction B(未提交)中修改的数据。比如transaction B对R记录修改了,但未提交。此时,在transaction A中读取R记录,读出的是被B修改过的数据。

可能发生的问题:脏读。

问题

我们看到,当执行不同的隔离级别时,可能会发生各种各样不同的问题。下面对它们进行总结并举例说明。

幻读

幻读发生在当两个完全相同的查询执行时,第二次查询所返回的结果集跟第一个查询不相同。

发生的情况:没有范围锁。

例子:

事务1 事务2
SELECT
* FROM
users
WHERE
age BETWEEN
10
AND
30

INSERT
INTO
users VALUES
(
3
, ‘Bob’
, 27
);
COMMIT;
SELECT
* FROM
users WHERE
age BETWEEN
10
AND
30;

如何避免:实行序列化隔离模式,在任何一个低级别的隔离中都可能会发生。

不可重复读
在基于锁的并行控制方法中,如果在执行select时不添加读锁,就会发生不可重复读问题。
在多版本并行控制机制中,当一个遇到提交冲突的事务需要回退但却被释放时,会发生不可重复读问题。

事务1 事务2
SELECT
* FROM
users WHERE
id = 1;

UPDATE
users SET
age = 21
WHERE
id = 1
;
COMMIT; /* in multiversion concurrency*/
control, or lock-based READ COMMITTED *
SELECT
* FROM
users WHERE
id = 1;

COMMIT; /* lock-based REPEATABLE READ */

在上面这个例子中,事务2提交成功,它所做的修改已经可见。然而,事务1已经读取了一个其它的值。在序列化和可重复读的隔离级别中,数据库管理系统会返回旧值,即在被事务2修改之前的值。在提交读和未提交读隔离级别下,可能会返回被更新的值,这就是“不可重复读”。

有两个策略可以防止这个问题的发生:
1. 推迟事务2的执行,直至事务1提交或者回退。这种策略在使用锁时应用。(悲观锁机制,比如用select for update为数据行加上一个排他锁)
2. 而在多版本并行控制中,事务2可以被先提交。而事务1,继续执行在旧版本的数据上。当事务1终于尝试提交时,数据库会检验它的结果是否和事务1、事务2顺序执行时一样。如果是,则事务1提交成功。如果不是,事务1会被回退。(乐观锁机制)

脏读
脏读发生在一个事务A读取了被另一个事务B修改,但是还未提交的数据。假如B回退,则事务A读取的是无效的数据。这跟不可重复读类似,但是第二个事务不需要执行提交。

事务1 事务2
SELECT
* FROM
users WHERE
id = 1;

UPDATE
users SET
age = 21
WHERE
id = 1
SELECT
FROM
users WHERE
id = 1;

COMMIT; /* lock-based DIRTY READ */
————————————————
原文链接:https://blog.csdn.net/as02446418/article/details/46986425