数据库高并发下乐观锁的原理

在高并发下,经常需要处理SELECT之后,在业务层处理逻辑,再执行UPDATE的情况。

  若两个连接并发查询同一条数据,然后在执行一些逻辑判断或业务操作后,执行UPDATE,可能出现与预期不相符的结果。

  在不使用悲观锁与复杂SQL的前提下,可以使用乐观锁处理该问题,同时兼顾性能。


  场景模拟:

  假设一张表两个字段,一个id,一个use_count。
表里存了100个id,每个id对应自己的use_count。

  当id每使用一次,use_count要加1。当use_count大于1000时,这个id就不能在被使用了(换句话说 无法从数据库中查出)。

  在高并发情况下,会遇到一种问题:假设数据表中有一条记录为:id=123456, use_count=999
  A与B两个连接并发查询这个id=123456,都执行下列SQL:

1
SELECT  FROM  table  WHERE  id=123456  and  use_count < 1000;

  A先执行,得到id=123456的use_count是999,之后在程序里做了一些逻辑判断或业务操作后执行SQL:

1
UPDATE  table  SET  use_count + 1  WHERE  id=123456;

  在A做判断且没有update之前,B也执行了查询SQL,发现use_count是999,之后它也会执行SQL:

1
UPDATE  table  SET  use_count + 1  WHERE  id=123456;

  但是,事实上B不应该取得这个id,因为A已经是第1000个使用者。

  处理步骤如下:

  1、添加第3个字段version,int类型,default值为0。version值每次update时作加1处理。

1
ALTER  TABLE  table  ADD  COLUMN  version  INT  DEFAULT  '0'  NOT  NULL  AFTER  use_count;

  2、SELECT时同时获取version值(例如为3)。

1
SELECT  use_count, version  FROM  table  WHERE  id=123456  AND  use_count < 1000;

  3、UPDATE时检查version值是否为第2步获取到的值。

1
UPDATE  table  SET  version=4, use_count=use_count+1  WHERE  id=123456  AND  version=3;

  如果UPDATE的记录数为1,则表示成功。
如果UPDATE的记录数为0,则表示已经被其他连接UPDATE过了,需作异常处理

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值