（转）如何正解决库存超卖问题 --乱

　　一般电子商务网站都会遇到如团购、秒杀、特价之类的活动，而这样的活动有一个共同的特点就是访问量激增、上千甚至上万人抢购一个商品。然而，作为活动商品，库存肯定是很有限的，如何控制库存不让出现超买，以防止造成不必要的损失是众多电子商务网站程序员头疼的问题，这同时也是最基本的问题。
　　本文来源：http://blog.csdn.net/caomiao2006/article/details/38568825，并就作者相关看法作了少量修改。

[内容]
　　注意！文中说到缓存用memcache，并以此作库存操作控制！作者认为应使用redis替代memcache，原因是redis支持事务，原子性与隔离性比memcache好。因此需要注意此点。

　　从技术方面剖析，很多人肯定会想到事务，但是事务是控制库存超卖的必要条件，但不是充分必要条件。
举例：总库存：4个商品，请求人：a、1个商品 b、2个商品 c、3个商品
示例如下：

begin...
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后，生成新的版本；这样执行完后，库存肯定为负数了。

　　下面我们来改造一下代码：

begin....
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){
       thrownewException('库存不足');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit....

　　再优化一下，如：

begin...
try{
    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');
}catch($e Exception){
    rollBack(回滚)
}
commit...

　　但是，使用事务也会带来性能问题，下面我们来分析一下：

1. 在秒杀的情况下，肯定不能如此高频率的去读写数据库，会严重造成性能问题的必须使用缓存，将需要秒杀的商品放入缓存中，并使用锁来处理其并发情况。当接到用户秒杀提交订单的情况下，先将商品数量递减（加锁/解锁）后再进行其他方面的处理，处理失败在将数据递增1（加锁/解锁），否则表示交易成功。当商品数量递减到0时，表示商品秒杀完毕，拒绝其他用户的请求。
2. 这个肯定不能直接操作数据库的，会挂的。直接读库写库对数据库压力太大，要用缓存。把你要卖出的商品比如10个商品放到缓存中；然后在memcache里设置一个计数器来记录请求数，这个请求书你可以以你要秒杀卖出的商品数为基数，比如你想卖出10个商品，只允许100个请求进来。那当计数器达到100的时候，后面进来的就显示秒杀结束，这样可以减轻你的服务器的压力。然后根据这100个请求，先付款的先得后付款的提示商品以秒杀完。
3. 首先，多用户并发修改同一条记录时，肯定是后提交的用户将覆盖掉前者提交的结果了。

　　
　　如果不采用事务，我们采用数据库锁来实现，锁分为乐观锁或者悲观锁。

• 乐观锁：就是在数据库设计一个版本号的字段，每次修改都使其+1，这样在提交时比对提交前的版本号就知道是不是并发提交了，但是有个缺点就是只能是应用中控制，如果有跨应用修改同一条数据乐观锁就没办法了，这个时候可以考虑悲观锁。

• 悲观锁，就是直接在数据库层面将数据锁死，类似于oralce中使用select xxxxx from xxxx where xx=xx for update，这样其他线程将无法提交数据。

　　其它思路我们也可以来发挥一下：
　　除了加锁的方式也可以使用接收锁定的方式，思路是在数据库中设计一个状态标识位，用户在对数据进行修改前，将状态标识位标识为正在编辑的状态，这样其他用户要编辑此条记录时系统将发现有其他用户正在编辑，则拒绝其编辑的请求，类似于你在操作系统中某文件正在执行，然后你要修改该文件时，系统会提醒你该文件不可编辑或删除。

[结论]
１，不建议在数据库层面加锁，建议通过服务端的内存锁（锁主键）。当某个用户要修改某个id的数据时，把要修改的id存入memcache，若其他用户触发修改此id的数据时，读到memcache有这个id的值时，就阻止那个用户修改。

２，实际应用中，并不是让mysql去直面大并发读写，会借助“外力”，比如缓存、利用主从库实现读写分离、分表、使用队列写入等方法来降低并发读写。

３，注意防止缓存穿透问题。即：如果缓存中所存商品的id范围可知，如100-1000，那么当我查询id为<100及1000的商品时，这里缓存中肯定是不存在的，按逻辑肯定会去查ＤＢ，查到后把数据放到缓存。这时问题来了，如果有人故意刷你这个范围外的东西，这样每次去查ＤＢ，并发量上来时，ＤＢ一定会挂。因此，为了避免这个问题，应在缓存放置当前数据存在的记录ＩＤ，通过ＩＤ确定是否需要查询ＤＢ。这样大大减轻了ＤＢ的压力。

 

 

REFS:http://blog.163.com/sujoe_2006/blog/static/335315120141139728398/