库存问题锁的思考

4.18,红色批注,并做了一些纠正

 

库存超卖的问题作描述:一般电子商务网站都会遇到如团购、秒杀、特价之类的活动,而这样的活动有一个共同的特点就是访问量激增、上千甚至上万人抢购一个商品。然而,作为活动商品,库存肯定是很有限的,如何控制库存不让出现超买,以防止造成不必要的损失是众多电子商务网站程序员头疼的问题,这同时也是最基本的问题。
从技术方面剖析,很多人肯定会想到事务,但是事务是控制库存超卖的必要条件,但不是充分必要条件。
举例:
总库存:4个商品
请求人:a、1个商品 b、2个商品 c、3个商品
程序如下:

1
2
3
4
5
6
7
8
9
10
11
beginTranse(开启事务)
try{
    $result $dbca->query('select amount from s_store where postID = 12345');
    if(result->amount > 0){
        //quantity为请求减掉的库存数量
        $dbca->query('update s_store set amount = amount - quantity where postID = 12345');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)

  


以上代码就是我们平时控制库存写的代码了,大多数人都会这么写,看似问题不大,其实隐藏着巨大的漏洞。数据库的访问其实就是对磁盘文件的访问,数据库中的表其实就是保存在磁盘上的一个个文件,甚至一个文件包含了多张表。例如由于高并发,当前有三个用户a、b、c三个用户进入到了这个事务中,这个时候会产生一个共享锁,所以在select的时候,这三个用户查到的库存数量都是4个,同时还要注意,mysql innodb查到的结果是有版本控制的,再其他用户更新没有commit之前(也就是没有产生新版本之前),当前用户查到的结果依然是旧版本;

然后是update,假如这三个用户同时到达update这里,这个时候update更新语句会把并发串行化,也就是给同时到达这里的是三个用户排个序,一个一个执行,并生成排他锁,在当前这个update语句commit之前,其他用户等待执行,commit后,生成新的版本;这样执行完后,库存肯定为负数了。但是根据以上描述,我们修改一下代码就不会出现超买现象了,代码如下:


1
2
3
4
5
6
7
8
9
10
11
12
beginTranse(开启事务)
try{
    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where postID = 12345');
    $result $dbca->query('select amount from s_store where postID = 12345');
    if(result->amount < 0){
       throw new Exception('库存不足');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)
或者

就是在update时,代入之前的库存作为条件,如:
update stocks set count=count-1 where count=20 and productid=xxxx

这样,在并发时,如果存在多条同时update,那么只有一条是成功的,其他的不会写入数据,也不需要回滚,只需要获得是否update成功的信息,就转去相应的处理界面就可以了。

 

 

这个地方业务上没有问题,存在一个大的关键点,即开启事务:

如果不开启事务,看一下业务流程

A                  B

update

                 update

select

                 select

如果此时库存1,B线程update直接提交,rc、rr级别下都立即对A可见

这里解释一下rr级别,如果A线程 select-update-select时,由于MVCC,B线程的update提交对A是不可见的,但是这里是update-select操作,B线程update提交后立即对A可见,那么此时A线程显示库存-1,返回客户端下单失败的结果,错误

 

再来看开启事务情况:

A                  B

update

                 阻塞

select 

提交

                update

                 select

                 提交

 

不存在并发问题,但整个过程是一个基于数据库的分布式悲观锁

 

1.用额外的单进程处理一个队列,下单请求放到队列里,一个个处理,就不会有并发的问题了,但是要额外的后台进程以及延迟问题,不予考虑。

2.数据库乐观锁,大致的意思是先查询库存,然后立马将库存+1,然后订单生成后,在更新库存前再查询一次库存,看看跟预期的库存数量是否保持一致,不一致就回滚,提示用户库存不足。

3.根据update结果来判断,我们可以在sql2的时候加一个判断条件update ... where 库存>0,如果返回false,则说明库存不足,并回滚事务。

4.借助文件排他锁,在处理下单请求的时候,用flock锁定一个文件,如果锁定失败说明有其他订单正在处理,此时要么等待要么直接提示用户"服务器繁忙"

5.redis incrby

http://www.cnblogs.com/adtuu/p/4688230.html

 

方案1:异步单线程

用于非实时场景,异步提交到消息队列,队列单线程原子一个一个操作,然后异步返回给用户最终状态

 

方案2:乐观锁,不开事务,RC级别

 

while(true){

  scount , sversion = select count, version from ku;

  if(scount > 0){

    lined = update ku set count = count-1 where version = sversion;

    if(lined > 0) {

      commit;      // 此句错误,这里无需使用事务,如果启用事务,虽然整个业务没有并发问题,但是与悲观锁无异,update操作会阻塞其它线程,直到commit,version形同虚设

      break;

    }

  } else {

    rollback;        // 同上

  }

}

 

 

方案3:   不开事务

lined = update ku set count = count-1 where count>0;

if(lined > 0)

  commit;           // 同上,不需要(如无其它数据库操作)

else

  rollback;           // 同上,不需要

 

方案4:悲观锁(假定数据库非自动提交)开事务

count = select count from ku for update;  // 排它锁,其它线程读阻塞,与3中update本质相同,都是基于数据库的分布式悲观锁,形式上不同,这里要事务,否则select直接提交了,没有锁的功能

if(count > 0)

  commit;

else

  rollback;

 

本次事务提交之前,外界无法修改这些记录, 但是事物提交后,会释放事务过程中的锁...注:要使用悲观锁,我们必须关闭mysql数据库的自动提交属性,因为MySQL默认使用auto...

 

 

方案5:redis

 

count = incrby(rcount, -1);

if(count > 0)

  do

else

  back;

 
 
注释:如果mysql也支持更新后返回更新后的值,即更新与读取保持原子操作,也可以
 
scount = update count=count-1 
if(scount > 0)
  do;
else
  back;

 

 

 

 

============================

1.代码同步, 例如使用 synchronized ,lock 等同步方法   开事务
1)spring包装类吧事务放在了同步的外面
2)单点
 
2.不查询,直接更新  update table set surplus = (surplus - buyQuantity) where id = xx and (surplus - buyQuantity) > 0   不开事务

1). 不具备通用性,例如add操作

2). 库存操作一般要记录操作前后的数量等,这样没法记录

3). 其他...

4)不具备事务回滚,只能手工回滚 

5)如果开了事务,则与4无不同  update会被其它未commit的update阻塞
3.使用CAS, update table set surplus = aa where id = xx and version = y   不开事务
 必须RC
4.使用数据库锁, select xx for update  开事务
 
5.使用分布式锁(zookeeper,redis等)
--------------------- 
作者:北京-小北 
来源:CSDN 
原文:https://blog.csdn.net/qq315737546/article/details/76850173 
版权声明:本文为博主原创文章,转载请附上博文链接!

 

posted on 2017-10-20 23:04  silyvin  阅读(259)  评论(0编辑  收藏  举报