数据库悲观锁与乐观锁Word下载.docx

数据库悲观锁与乐观锁Word下载.docx

《数据库悲观锁与乐观锁Word下载.docx》由会员分享，可在线阅读，更多相关《数据库悲观锁与乐观锁Word下载.docx（24页珍藏版）》请在冰点文库上搜索。

在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出goods信息后就把当前的数据锁定，直到我们修改完毕后再解锁。

那么在这个过程中，因为goods被锁定了，就不会出现有第三者来对其进行修改了。

selectstatusfromt_goodswhereid=1 

forupdate;

//4.提交事务

commit;

/commitwork;

上面的第一步我们执行了一次查询操作：

selectstatusfromt_goodswhereid=1forupdate;

与普通查询不一样的是，我们使用了select…forupdate的方式，这样就通过数据库实现了悲观锁。

此时在t_goods表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。

这样我们可以保证当前的数据不会被其它事务修改。

注：

需要注意的是，在事务中，只有SELECT...FORUPDATE或LOCKINSHAREMODE同一笔数据时会等待其它事务结束后才执行，一般SELECT...则不受此影响。

拿上面的实例来说，当我执行selectstatusfromt_goodswhereid=1forupdate;

后。

我在另外的事务中如果再次执行selectstatusfromt_goodswhereid=1forupdate;

则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行selectstatusfromt_goodswhereid=1;

则能正常查询出数据，不会受第一个事务的影响。

举例说明：

数据库表t_goods，包括id,status,name三个字段，id为主键，数据库中记录如下;

Sql代码 

1.mysql>

select 

* 

from 

t_goods;

2.+----+--------+------+ 

3.| 

id 

| 

status 

name 

4.+----+--------+------+ 

5.| 

1 

道具 

6.| 

2 

装备 

7.+----+--------+------+ 

8.2 

rows 

in 

set 

9. 

10.mysql>

mysql>

select*fromt_goods;

+----+--------+------+|id|status|name|+----+--------+------+|1|1|道具||2|1|装备|+----+--------+------+2rowsinsetmysql>

为了测试数据库锁，我使用两个console来模拟不同的事务操作，分别用console1、console2来表示。

例1:

（明确指定主键，并且有此数据，rowlock）

console1：

查询出结果，但是把该条数据锁定了

t_goods 

where 

id=1 

for 

update;

6.+----+--------+------+ 

7.1 

row 

8. 

9.mysql>

select*fromt_goodswhereid=1forupdate;

+----+--------+------+|id|status|name|+----+--------+------+|1|1|道具|+----+--------+------+1rowinsetmysql>

console2：

查询被阻塞

如果console1长时间未提交，则会报错

2.ERROR 

1205 

:

Lock 

wait 

timeout 

exceeded;

try 

restarting 

transaction 

ERROR1205:

Lockwaittimeoutexceeded;

tryrestartingtransaction

例2:

（明确指定主键，若查无此数据，无lock）

查询结果为空

id=3 

2.Empty 

select*fromt_goodswhereid=3forupdate;

Emptyset

查询结果为空，查询无阻塞，说明console1没有对数据执行锁定

例3:

（无主键，tablelock）

查询name=道具的数据，查询正常

name='

道具'

select*fromt_goodswherename='

forupdate;

查询name=装备的数据，查询阻塞，说明console1把表给锁住了

装备'

若console1长时间未提交，则查询返回为空

2.Query 

OK, 

-1 

affected 

QueryOK,-1rowsaffected

例4:

（主键不明确，tablelock）

查询正常

begin;

0 

3. 

4.mysql>

id>

5.+----+--------+------+ 

8.| 

9.| 

10.+----+--------+------+ 

11.2 

12. 

13.mysql>

begin;

QueryOK,0rowsaffectedmysql>

select*fromt_goodswhereid>

0forupdate;

查询被阻塞，说明console1把表给锁住了

1forupdate;

例5:

id<

>

9.+----+--------+------+ 

10.1 

11. 

12.mysql>

select*fromt_goodswhereid<

+----+--------+------+|id|status|name|+----+--------+------+|2|1|装备|+----+--------+------+1rowinsetmysql>

2forupdate;

提交事务

commit;

QueryOK,0rowsaffected

console1事务提交后，console2查询结果正常

举例：

我们修改t_goods表，给status字段创建一个索引

修改id为2的数据的status为2，此时表中数据为：

+----+--------+------+|id|status|name|+----+--------+------+|1|1|道具||2|2|装备|+----+--------+------+2rowsinsetmysql>

例6:

（明确指定索引，并且有此数据，rowlock）

status=1 

select*fromt_goodswherestatus=1forupdate;

查询status=1的数据时阻塞，超时后返回为空，说明数据被console1锁定了

查询status=2的数据，能正常查询，说明console1只锁住了行，未锁表

status=2 

select*fromt_goodswherestatus=2forupdate;

+----+--------+------+|id|status|name|+----+--------+------+|2|2|装备|+----+--------+------+1rowinsetmysql>

例7:

（明确指定索引，若查无此数据，无lock）

查询status=3的数据，返回空数据

status=3 

select*fromt_goodswherestatus=3forupdate;

谈到了MySQL悲观锁，但是悲观锁并不是适用于任何场景，它也有它存在的一些不足，因为悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。

如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是对长事务而言，这样的开销往往无法承受。

所以与悲观锁相对的，我们有了乐观锁，具体参见下面介绍：

乐观锁介绍：

乐观锁（OptimisticLocking）相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

那么我们如何实现乐观锁呢，一般来说有以下2种方式：

1.使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。

何谓数据版本？

即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的“version”字段来实现。

当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。

当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。

用下面的一张图来说明：

如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。

但是如果发生有不同的业务操作对同一版本的数据进行修改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失败。

2.乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）,和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

使用举例：

还是拿之前的实例来举：

下单操作包括3步骤：

1.查询出商品信息

select（status,status,version）fromt_goodswhereid=#{id}

2.根据商品信息生成订单

3.修改商品status为2

updatet_goods 

setstatus=2,version=version+1

whereid=#{id} 

andversion=#{version};

那么为了使用乐观锁，我们首先修改t_goods表，增加一个version字段，数据默认version值为1。

t_goods表初始数据如下：

2.+----+--------+------+---------+ 

version 

4.+----+--------+------+---------+ 

2