库存问题锁的思考
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;
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
1). 不具备通用性,例如add操作
2). 库存操作一般要记录操作前后的数量等,这样没法记录
3). 其他...
4）不具备事务回滚，只能手工回滚
