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

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

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

可以基于例如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);
?>

转载于:https://www.cnblogs.com/long613/p/7736143.html

转（解决抢购、秒杀、抢楼、抽奖等阻塞式高并发库存防控超量的思路方法）...相关推荐

php秒杀防重复中奖_PHP解决抢购、秒杀、抢楼、抽奖等阻塞式高并发库存防控超量的思路方法...
现在在电商行业里,秒杀抢购活动已是商家经常使用促销手段.可是库存数量有限,而同时下单人数超过了库存量,就会致使商品超卖甚至库存变负数的问题. 又好比:抢购火车票.论坛抢楼.抽奖乃至爆红微博评论等也会引 ...
高并发库存秒杀场景，阿里巴巴数据库是这样应对的
简单库存场景的数据库实现一般来说,从数据库层面讲,库存业务会分为两步,第一步是插入一条记录到扣减明细表inventory_detail,第二步是对库存扣减表inventory的一条记录进行扣减,这两 ...
JAVA秒杀mysql层实现_Java商城高并发秒杀系统架构分析设计与开发实战
课程大纲 1-1课程整体介绍.mp4 1-2核心技术列表.mp4 1-3课程要求与收益.mp4 1-4系统的整体演示.mp4 2-1微服务项目的搭建-SpringBoot搭建多模块项目一.mp4 2- ...
分布式、高并发、高性能场景(抢购、秒杀、抢票、限时竞答)数据一致性解决方案
技术指标: PV(Page View, 页面浏览量)在千万级别 QPS(Query Per Second, 每秒处理请求数)在百万级别数据量在千亿级别接口响应速度不能超过150毫秒用户提交请求到 ...
分布式、高并发、高性能场景(抢购、秒杀、抢票、限时竞答)数据一致性解决方案...
技术指标: PV(Page View, 页面浏览量)在千万级别 QPS(Query Per Second, 每秒处理请求数)在百万级别数据量在千亿级别接口响应速度不能超过150毫秒用户提交请求到 ...
PHP收费事件导致用户流失,PHP秒杀系统方案(解决大流量,高并发)
抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个: 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少("超卖"问题) 对于第一个问题,已经很容易想到 ...
91免费视频Redis+Lua解决高并发场景在线秒杀问题
为何要使用Lua脚本解决商品超卖的问题呢? Redis在2.6版本后原生支持Lua脚本功能,允许开发者使用Lua语言编写脚本传到Redis中执行. 将复杂的或者多步的redis操作,写为一个脚本,一次 ...
Day267.预约系统的性能瓶颈、营销活动无缝切换秒杀活动、预约系统数据迁移方案、高流量下预约系统搭建熔断机制、预约系统redis集群主从哨兵架构 -Redis的高并发预约抢购系统
一.预约系统的性能瓶颈 1.预约系统应对热门爆品时的缺陷用户进行预约会涉及到两个维度的数据变更一个是用户信息,一个是SKU信息,如图↓所示: 正常来说这么搞一点问题没有,即便涉及到写数据库,但是每个 ...
高级IO（文件的读写）——并发式IO的解决方案（解决多路阻塞式IO的方案）
以下内容源于朱有鹏<物联网大讲堂>课程的学习整理,如有侵权,请告知删除. 一.并发式IO的解决方案所谓并发式IO,即上节中提及的鼠标和键盘都已经启动. 1.非阻塞式IO 使用fcntl函 ...
哎呀，你对高并发与多线程的解决思路了解的还挺深！
一.大规模并发带来的挑战在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战.如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态.我们现在 ...

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

转（解决抢购、秒杀、抢楼、抽奖等阻塞式高并发库存防控超量的思路方法）...相关推荐

最新文章

热门文章