假如有一个购买行为事务,我们更需要去跟新数据库

update item set amount = amount - 1 where item_id = 1;

然而当amount只有1个的时候,同时有两个顾客进入了事务进行购买行为会如何,最后amount=-1,两个顾客都获得了这个商品,这显然不合理

而使用乐观锁和悲观锁的解决方案可以如下:

 

1. 乐观锁

1) 概念: 在执行修改操作时不判断是否存在冲突,而是到了操作完成后再判断是否存在冲突,如有冲突则回滚

2) 适用情况: 一般适用于回滚代价低,且冲突较少的情况.

3) 优点: 执行操作时不会造成阻塞

4) 缺点: 如果冲突较多,将造成较多的回滚操作

5) 实现: 一般使用版本控制的方式实现

6) 实现例子:

begin;

select @cur_amount := amount from item where item_id = 1;

update item set amount = amount - 1 where amount = @cur_amount and item_id = 1;

commit;

// 最后根据是否对数据更新行数是否为1来告诉用户是否购买成功

这是使用乐观锁来更新的例子, @cur_amount是本次事务A获得的数量, 例如为 1, 而另外一个事务B假如于事务A之前执行完了跟新操作, 那么此时数据库中的amount将变为0.

那么事务A的 update 中语句 amount = @cur_amount 将是 0 = 1 而不成立, 所以此次购买会失败

我这里只是一个简单的例子,实际操作中,可能这个事务中间会进行大量操作,而最后会因为amount != @cur_amount 而回滚

例如java中使用AtomicInteger的乐观锁实现(待补完)

 

2. 悲观锁

1) 概念: 在执行操作前就进行是否需要锁的判断,加入有操作正在执行,则需要等待锁释放

2) 适用情况: 冲突较多的情况

3) 优点: 不需要进行回滚

4) 缺点: 需要串行执行, 会造成阻塞

5) 实现: 使用排他锁

6) 实现例子:

begin;

select amount from item where item_id = 1 for update;

// 通过amount来做出一些行为,例如告诉用户库存不足,购买失败,然后只有amount > 1才进入更新库存操作

update item set amount = amount - 1 where item_id = 1;

commit;

由于是串行执行,其他事务的for update必须等该当前事务的for update语句执行,所以我们不必担心我们获得的amount被修改过,因为它永远是最新的

 

事实上,对于这种购买行为的解决方案是使用

update item set amount = amount - 1 where item_id = 1 and amount > 0;

由于update操作在repeatable-read中是串行执行的,所以我们大可以不加锁,直接这么一句就解决了

当然这是一种特例,上述我只是为了解释乐观锁与悲观锁,因为实在没找到什么好的例子.