使用 redis 减少 秒杀库存 超卖思路

由于数据库查询的及插入的操作 耗费的实际时间要耗费比redis 要多,

导致 多人查询时库存有,但是实际插入数据库时却超卖

redis 会有效的减少相关的延时,对于并发量相对较少的 可以一用

 1     public function buy($goods_id = 0){
 2         if(!$goods_id){
 3             die("商品不存在!");
 4         }
 5         $redis = new Redis();
 6         $redis->connect(‘127.0.0.1‘,6379);
 7         $stock = 0;
 8         if(!$redis->get("gid".$goods_id)){
 9             $stock = get_stock($goods_id); //从数据看获取实际库存
10             $redis->set("gid".$goods_id,$stock);
11         }else{
12             $stock = $redis->get("gid".$goods_id);
13         }
14
15         if($stock > 0){
16             //逻辑操作 代码
17             //coding here...
18             set("gid".$goods_id,$stock-1);
19         }else{
20             die("已卖完!");
21         }
22     }  
时间: 2024-11-10 08:11:34

使用 redis 减少 秒杀库存 超卖思路的相关文章

秒杀踩坑记:库存超卖

本案例发生在别人身上,觉得有学习借鉴的意义特转载过来记录一下. PM 说有一个类似于抢购的小需求,我们第一反应就想到是典型的防止库存超卖场景,于是理所因当地选用了 Redis 方案.只要保证是原子操作,即可防止库存超卖,自然想到使用 Incr/Decr 这类原子操作. 查看 PHP 的 Redis 扩展关于 Incr 方法的说明: /** * Increment the number stored at key by one. * * @param string $key * @return i

mysql处理高并发,防止库存超卖

先来就库存超卖的问题作描述:一般电子商务网站都会遇到如团购.秒杀.特价之类的活动,而这样的活动有一个共同的特点就是访问量激增.上千甚至上万人抢购一个商品.然而,作为活动商品,库存肯定是很有限的,如何控制库存不让出现超买,以防止造成不必要的损失是众多电子商务网站程序员头疼的问题,这同时也是最基本的问题. 从技术方面剖析,很多人肯定会想到事务,但是事务是控制库存超卖的必要条件,但不是充分必要条件. 举例: 总库存:4个商品 请求人:a.1个商品 b.2个商品 c.3个商品 程序如下: beginTr

转 mysql处理高并发,防止库存超卖

原文地址: mysql处理高并发,防止库存超卖 今天王总又给我们上了一课,其实MySQL处理高并发,防止库存超卖的问题,在去年的时候,王总已经提过:但是很可惜,即使当时大家都听懂了,但是在现实开发中,还是没这方面的意识.今天就我的一些理解,整理一下这个问题,并希望以后这样的课程能多点. 先来就库存超卖的问题作描述:一般电子商务网站都会遇到如团购.秒杀.特价之类的活动,而这样的活动有一个共同的特点就是访问量激增.上千甚至上万人抢购一个商品.然而,作为活动商品,库存肯定是很有限的,如何控制库存不让出

(转)mysql处理高并发,防止库存超卖

原文链接:http://blog.csdn.net/caomiao2006/article/details/38568825 今天王总又给我们上了一课,其实mysql处理高并发,防止库存超卖的问题,在去年的时候,王总已经提过:但是很可惜,即使当时大家都听懂了,但是在现实开发中,还是没这方面的意识.今天就我的一些理解,整理一下这个问题,并希望以后这样的课程能多点. 先来就库存超卖的问题作描述:一般电子商务网站都会遇到如团购.秒杀.特价之类的活动,而这样的活动有一个共同的特点就是访问量激增.上千甚至

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

背景: 本人上次做申领campaign的PHP后台时,因为项目上线后某些时段同时申领的人过多,导致一些专柜的存货为负数(<0),还好并发量不是特别大,只存在于小部分专柜而且一般都是-1的状况,没有造成特别特别严重的后果,但还是要反思了自己的过错. 这次又有新的申领campaign,我翻看了上次的代码逻辑: 正文: [先select后update] beginTranse(开启事务) try{     $result = $dbca->query('select amount from s_st

关于秒杀和超卖的性能问题

一.秒杀带来了什么? 秒杀或抢购活动一般会经过[预约][抢订单][支付]这3个大环节,而其中[抢订单]这个环节是最考验业务提供方的抗压能力的. 抢订单环节一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题. 二.如何解决? 首先,产品解决方案我们就不予讨论了.我们只讨论技术解决方案 1.前端 面对高并发的

秒杀与超卖的 性能解决之路

一.秒杀带来了什么? 秒杀或抢购活动一般会经过[预约][抢订单][支付]这3个大环节,而其中[抢订单] 这个环节是最考验业务提供方的抗压能力的. 抢订单环节一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于 网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不 超过商品数量的上限,这是每个抢购活动都要面临的难题. 二.如何解决? 首先,产品解决方案我们就不予讨论了.我们只讨论技术解决方案 1.前端 面对高

对于业务中库存超卖测试

多并发时,用相应的锁方案保证库存不发生超卖.实现这个方案后,要有相应的场景测试方案. 很多时候,验证方案非常重要. java可以利用CountDownLatch测试多并发.CountDownlatch通常用于某个业务线程需要等待其它多个线程完成某个条件后才进行相应操作. CountDownLatch有countDown及await方法,分别对应减少计数器及当计数器大于0时阻塞当前线程.当计数量等于0时所有调用await方法且被阻塞的线程都被唤醒,然后进行相应操作. 此处用于模拟10个并发用户进行

redis分布式锁解决超卖问题

1.1 redis事物 1.redis事物介绍 1. redis事物是可以一次执行多个命令,本质是一组命令的集合. 2. 一个事务中的所有命令都会序列化,按顺序串行化的执行而不会被其他命令插入 作用:一个队列中,一次性.顺序性.排他性的执行一系列命令 2.multi 指令基本使用 1. 下面指令演示了一个完整的事物过程,所有指令在exec前不执行,而是缓存在服务器的一个事物队列中 2. 服务器一旦收到exec指令才开始执行事物队列,执行完毕后一次性返回所有结果 3. 因为redis是单线程的,所