解决抢购秒杀抽奖等大流量并发入库导致的库存负数的问题

我们知道数据库处理sql是一条条处理的，假设购买商品的流程是这样的：

sql1:查询商品库存

if(库存数量 > 0)
{
  //生成订单...
  sql2:库存-1
}

当没有并发时，上面的流程看起来是如此完美，假设同时两个人下单，而库存只有1个了，在sql1阶段两个人查询到的库存都是>0的，于是最终都执行了sql2，库存最后变为-1，超售了，要么补库存，要么等用户投诉吧。

解决这个问题比较流行的思路：

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

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

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

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

本文要说的是第4种方案，大致代码如下：

阻塞(等待)模式

<?php
$fp = fopen("lock.txt", "w+");
if(flock($fp,LOCK_EX))
{
  //..处理订单
  flock($fp,LOCK_UN);
}
fclose($fp);
?>

非阻塞模式

<?php
$fp = fopen("lock.txt", "w+");
if(flock($fp,LOCK_EX | LOCK_NB))
{
  //..处理订单
  flock($fp,LOCK_UN);
}
else
{
  echo "系统繁忙，请稍后再试";
}

fclose($fp);
?>

1、一般避免并发情况可以通过：声明synchronized、数据库加锁、乐观/悲观锁、ThreadLocal对象等来实现 

2、像你这种情况，个人建议： 
1）使用悲观锁 
  a）基于jdbc实现的数据库加锁如下： 
     select * from account where name="Erica" for update.在更新的过程中，数据库处于加锁状态，任何其他的针对本条数据的操作都将被延迟。本次事务提交后解锁。 
  b）基于hibernate悲观锁的具体实现如下： 
     String sql="查询语句"; 
     Query query = session.createQuery(sql); 
     query.setLockMode("对象"，LockModel.UPGRADE); 
从系统的性能上来考虑，对于单机或小系统而言，这并不成问题，然而如果是在网络上的系统，同时间会有许多联机，假设有数以百计或上千甚至更多的并发访问出现，那后果可能难以想象 

2）使用乐观锁 
    悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。 

    乐观锁 大多是基于数据版本 （Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来 实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 

举例说明： 
A客户读取账户余额1000元，并连带读取版本号为5的话， 
B客户此时也读取账号余额1000元，版本号也为5， 
A客户在领款后账户余额为500，此时将版本号加1，版本号目前为6，而数据库中版本号为5，所以予以更新，更新数据库后，数据库此时余额为500，版本号为6， 
B客户领款后要变更数据库，其版本号为5，但是数据库的版本号为6，此时不予更新， 
B客户数据重新读取数据库中新的数据并重新进行业务流程才变更数据库。 


    需要注意的是：乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局 限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作（即有其他系统使用了跟本系统相同的数据库，并对其操作）不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。