乐观锁与悲观锁

针对不同的业务场景,应该选用不同的并发控制方式。所以,不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念,更不要把他们和数据库中提供的锁机制(行锁、表锁、排他锁、共享锁)混为一谈。其实DBMS中,悲观锁正是利用数据库本身提供的锁机制实现的。

悲观锁

在关系数据库管理系统中,悲观并发控制是一种并发控制方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务的执行擦偶作对某行数据应用了锁,那只有当这个事务把锁释放,其他事务才能够执行与该锁冲突的操作。

悲观并发控制主要用于数据争用激烈的环境,以及发生并发控制时使用锁保护数据的成本低于回滚食物的成本中。

悲观锁,具有强烈的独占和排他性。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改保持保守状态。因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现往往依靠数据库提供的锁机制(也只有数据库提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。

在数据库中,悲观锁的流程如下:

在对任何记录进行修改前,先尝试为该记录加上排他锁。

如果加锁失败,说明该记录正在被修改,那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。

如果加锁成功,那么就可以对记录进行修改,食物完成之后就会解锁。

其间如果有其他对该记录进行修改或者加排他锁的操作,都会等待我们解锁或直接抛出异常。

MySQL InnoDB中使用悲观锁
要使用悲观锁,我们必须关闭MySQL数据库的自动提交属性,因为MySQL默认使用autocommit模式,也就是说,当执行一个更新操作后,MySQL会立刻将结果进行提交。set autocommit=0;

//0.开始事务
begin;/begin work;/start transaction; (三者选一就可以)
//1.查询出商品信息
select status from t_goods where id=1 for update;
//2.根据商品信息生成订单
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status为2
update t_goods set status=2;
//4.提交事务
commit;/commit work;

上面的查询语句中,使用了select … for update的方式,这样就通过开启排他锁的方式实现了悲观锁。此时在t_goods表中,id为1的那条数据就被锁定了,其他的食物必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不被其他事务修改。

注意 使用select... for update会把数据给锁住,不过需要注意一下锁的级别,MySQL InnoDB默认行级锁,行级锁都是基于索引的,如果一条SQL语句用不到索是不会使用行级锁的,会使用表级锁把整张表锁住。

优点与不足

悲观并发控制实际上是“先取锁再访问”的保守策略,为数据处理的安全提供了保证。但在效率方面,处理加锁的机制会让数据库产生额外的开销,还有增加产生死锁的机会;另外,在只读型事务处理中由于不会产生冲突,也没必要使用锁,这样做只能增加系统负载;还有降低了并行性,一个事务如果锁定了某行数据,其他事务就必须等待该事物处理完才可以处理那行数据。

乐观锁

在关系数据库管理系统中,乐观并发控制(又名乐观锁)是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务先检查在该事务读取数据后,有没有其他事务修改了该数据。如果其他事务有更新的话,正在提交的事务会进行回滚。

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

相对于悲观锁,在对数据库进行处理的时候,乐观锁并不会使用数据库提供的锁机制,一般的实现乐观锁的方式就是记录数据版本。

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

实现数据版本有两种方式,一是使用版本号,二是使用时间戳

使用版本号实现乐观锁

使用版本号时,可以在数据初始化时指定一个版本号,每次对数据的更新操作都对版本号执行+1操作。并判断当前版本号是不是该数据的最新版本号

# 1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
# 2.根据商品信息生成订单
# 3.修改商品status为2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

优点与不足

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的,因此尽可能直接做下去,知道提交的时候才去锁定,所以不会产生任何锁或死锁。但如果直接简单这么做,还是有可能会遇到不可预期的结果,例如两个事务都读取了数据库的某一行,经过修改以后写会数据库,这时就遇到了问题。