PHP解决抢购、秒杀、抢楼、抽奖等阻塞式高并发库存防控超量的思路方法

2024-07-11 08:23| 来源: 网络整理| 查看: 265

如今在电商行业里,秒杀抢购活动已经是商家常用促销手段。但是库存数量有限，而同时下单人数超过了库存量，就会导致商品超卖甚至库存变负数的问题。

又比如：抢购火车票、论坛抢楼、抽奖乃至爆红微博评论等也会引发阻塞式高并发问题。如果不做任何措施可能在高瞬间造成服务器瘫痪，如何解决这个问题呢？

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

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

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

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

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

注意：

将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false

//库存减少 $sql="update ih_store set number=number-{$number} where sku_id='$sku_id' and number>0"; $store_rs=mysql_query($sql,$conn); if(mysql_affected_rows()){ insertLog('库存减少成功'); } 关于悲观锁和乐观锁：悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。方案一：使用消息队列来实现

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

先将商品库存如队列

抢购、描述逻辑

【本文地址】

公司简介

联系我们