Mysql在高并发情况下，防止库存超卖而小于0的解决方案

背景：

本人上次做申领campaign的PHP后台时，因为项目上线后某些时段同时申领的人过多，导致一些专柜的存货为负数（<0），还好并发量不是特别大，只存在于小部分专柜而且一般都是-1的状况，没有造成特别特别严重的后果，但还是要反思了自己的过错。

　　这次又有新的申领campaign，我翻看了上次的代码逻辑：

正文：

【先select后update】

beginTranse(开启事务)
try{
$result = $dbca->query('select amount from s_store where postID = 12345');
if(result->amount > 0){
$dbca->query('update s_store set amount = amount - 1 where postID = 12345');
}
}catch($e Exception){
rollBack(回滚)
}
commit(提交事务)

　　以上代码就是我第一次的写法，看似问题不大，其实隐藏着巨大的漏洞。数据库的访问其实就是对磁盘文件的访问，数据库中的表其实就是保存在磁盘上的一个个文件，甚至一个文件包含了多张表。例如由于高并发，当前有三个用户a、b、c三个用户进入到了这个事务中，这个时候会产生一个共享锁，所以在select的时候，这三个用户查到的库存数量都是>=0的。

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

【先update后select】

beginTranse(开启事务)
try{
$dbca->query('update s_store set amount = amount - 1 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 & select合并】

beginTranse(开启事务)
try{
$dbca->query('update s_store set amount = amount - 1 where amount>=1 and postID = 12345');
}catch($e Exception){
rollBack(回滚)
}
commit(提交事务)

========================================补充=============================================

1、这个肯定不能直接操作数据库的，会挂的。直接读库写库对数据库压力太大，要用缓存。

　　把你要卖出的商品比如10个商品放到缓存中；然后在memcache里设置一个计数器来记录请求数，这个请求书你可以以你要秒杀卖出的商品数为基数，比如你想卖出10个商品，只允许100个请求进来。那当计数器达到100的时候，后面进来的就显示秒杀结束，这样可以减轻你的服务器的压力。然后根据这100个请求，先付款的先得后付款的提示商品以秒杀完。

2、首先，多用户并发修改同一条记录时，肯定是后提交的用户将覆盖掉前者提交的结果了。这个直接可以使用加锁机制去解决，乐观锁或者悲观锁。

　　悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

　　乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

　　两种锁各有优缺点，不能单纯的定义哪个好于哪个。乐观锁比较适合数据修改比较少，读取比较频繁的场景，即使出现了少量的冲突，这样也省去了大量的锁的开销，故而提高了系统的吞吐量。但是如果经常发生冲突（写数据比较多的情况下），上层应用不不断的retry，这样反而降低了性能，对于这种情况使用悲观锁就更合适。

3、不建议在数据库层面加锁，建议通过服务端的内存锁（锁主键）。

　　当某个用户要修改某个id的数据时，把要修改的id存入memcache，若其他用户触发修改此id的数据时，读到memcache有这个id的值时，就阻止那个用户修改。

=======================================补充==============================================

参考资料:

【mysql处理高并发，防止库存超卖】http://blog.csdn.net/caomiao2006/article/details/38568825

锁机制 --- MYSQL中的锁和PHP中的锁

1、MYSQL中的表：

语法：LOCK TABLE 表名1 READ|WRITE, 表名2 READ|WRITE ..................

UNLOCK TABLES

Read读锁|共享锁 ：所有的客户端只能读这个表不能写这个表

Write写锁|排它锁：所有当前锁定客户端可以操作这个表，其他客户端只能阻塞

注意：在锁表的过程中只能操作被锁定的表，如果要操作其他表，必须把所有要操作的表都锁定起来！！

2、PHP中的文件锁

文件可以随意名字，只要是个文件就行。上面LOCK_EX 排他型。“此文件相当与钥匙，抢到钥匙的才能进门。”

总结：项目中应该只使用PHP中的文件锁，尽量避免锁表，因为如果表被锁定了，那么整个网站中所有和这个表相关的功能都被拖慢了。

应用场景：

1. 高并发下单时，减库存量时要加锁

2. 高并发抢单、抢票时要使用

如何模拟高并发访问一个脚本：可以使用APACHE中的ab.exe软件：

Ab.exe：apache中用来做压力测试。直接将ab.exe拖拽到dos黑窗中。

其它方案措施

如今在电商行业里,秒杀抢购活动已经是商家常用促销手段。但是库存数量有限，而同时下单人数超过了库存量，就会导致商品超卖甚至库存变负数的问题。
又比如：抢购火车票、论坛抢楼、抽奖乃至爆红微博评论等也会引发阻塞式高并发问题。如果不做任何措施可能在高瞬间造成服务器瘫痪，如何解决这个问题呢？
这里提出个人认为比较可行的几个思路方法：

方案一：使用消息队列来实现

可以基于例如MemcacheQ等这样的消息队列，具体的实现方案这么表述吧
比如有100张票可供用户抢，那么就可以把这100张票放到缓存中，读写时不要加锁。当并发量大的时候，可能有500人左右抢票成功，这样对于500后面的请求可以直接转到活动结束的静态页面。进去的500个人中有400个人是不可能获得商品的。所以可以根据进入队列的先后顺序只能前100个人购买成功。后面400个人就直接转到活动结束页面。当然进去500个人只是举个例子，至于多少可以自己调整。而活动结束页面一定要用静态页面，不要用数据库。这样就减轻了数据库的压力。

方案二：当有多台服务器时，可以采用分流的形式实现

假设有m张票, 有n台产品服务器接收请求,有x个请求路由服务器随机转发
直接给每台产品服务器分配 m/n张票
每台产品服务器内存做计数器,比如允许m/n*(1+0.1)个人进来。
当内存计数器已满：
后面进的人, 直接跳到到转到活动结束的静态页面，
通知路由服务器,不在路由到这台服务器(这个值得商讨)。
所有产品服务器进来的m/n*(1+0.1)个人再全部转发到一台付款服务器上,进入付款环节,看谁手快了,这时候人少,加锁什么的就简单的。

方案三、如果是单服务器，可以使用Memcache锁来实现

product_key 为票的key
product_lock_key 为票锁key
当product_key存在于memcached中时，所有用户都可以进入下单流程。
当进入支付流程时，首先往memcached存放add(product_lock_key, “1″),
如果返回成功，进入支付流程。
如果不成，则说明已经有人进入支付流程，则线程等待N秒，递归执行add操作。

方案四、借助文件排他锁
在处理下单请求的时候，用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);
?>

Mysql在高并发情况下，防止库存超卖而小于0的解决方案相关推荐

MySql（15）——Mysql在高并发情况下，防止库存超卖而小于0的解决方案
本人上次做申领campaign的PHP后台时,因为项目上线后某些时段同时申领的人过多,导致一些专柜的存货为负数(<0),还好并发量不是特别大,只存在于小部分专柜而且一般都是-1的状况,没有造成特 ...
在高并发情况下如何解决用户超领优惠券问题
在高并发情况下如何解决单用户超领优惠券问题一. 场景描述在近期的项目里面有一个功能是领取优惠券的功能,每一个优惠券一共发行多少张,每个用户可以领取多少张: 如:A优惠券一共发行120张,每一个用户 ...
高并发情况下修改系统参数
单进程最大打开文件数限制一般的发行版,限制单进程最大可以打开1024个文件,这是远远不能满足高并发需求的,调整过程如下: 在#号提示符下敲入: ulimit–n 65535 限制修改失败了,会显示 ...
wcf高并发 mysql_WCF服务在高并发情况下报目标积极拒绝的异常处理 z
http://www.cnblogs.com/kklldog/p/5037006.html wcf的监控服务,偶尔监控到目标服务会报一个目标积极拒绝的错误.一开始以为服务停止了,上服务器检查目标服务好 ...
随手记录第二话 -- 高并发情况下秒杀、抢红包都有哪些实现方式？
1.何为高并发? 高并发:在短时间内涌入超量的请求那么如果出现这几种情况,可能会导致的后果服务宕机商品库存,红包金额超量 2.何为高并发秒杀? 这是一个高频面试题,问题虽然简单,但是里面的细节有 ...
java rabbitmq 并发_RabbitMQ消息中间件高级篇二高并发情况下保障消息投递可靠性...
RabbitMQ消息中间件技术精讲9 高级篇二高并发场景下,消息的延迟投递做二次确认进行回调检查来保障生产者消息投递成功的可靠性在上一篇文章中,我们介绍了BAT大厂中一种方式保障生成者消息投递可靠 ...
集群高并发情况下如何保证分布式唯一全局ID生成
作者:轻狂书生 blog.csdn.net/LookForDream_/article/details/109355335 前言系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问 ...
高并发场景下的库存更新
在高并发的情况下,肯定不能高频率的去读写数据库,会严重造成性能问题的必须使用缓存,将需要秒杀的商品放入缓存中,并使用锁来处理其并发情况.当接到用户秒杀提交订单的情况下,先将商品数量递减(加锁/解锁) ...
高并发情况下保证高可用性
0.高并发 0.1.什么是高并发高并发(High Concurrency)是一种系统运行过程中遇到的一种"短时间内遇到大量操作请求"的情况,主要发生在web系统集中大量访问收到大 ...

Mysql在高并发情况下，防止库存超卖而小于0的解决方案

Mysql在高并发情况下，防止库存超卖而小于0的解决方案相关推荐

最新文章

热门文章