记一次用户抢购商品导致服务器炸了

没付款的库存就留明天抢购嘛，都一样的

可以写个定时任务，30分钟之后未付款的库存在加回去

@晓轩 30分钟后可能抢购都结束了，真想抢购的没抢购，抢到的又不付钱，我看限时抢购应该付钱了再减库存。

1、下单减库存。即生成一个订单，库存减1 。这种情况，会出现恶意下单情况，用户只下单，不付款。

2、付款减库存。即订单付完款后才减去相应的库存。这种处理方式不会出现1内的问题，但会出现用户拍下时有货，付款后没货的情况，用户体验极差 :joy:。

@一个人的江湖 所以说多备点货才是最好的解决方法 :joy:

用 redis 单线程不会出现重复问题，同一个地址 ip 手机号都该认为是同一个用户，限制用户，然后客户端可以加个验签，访问做个限制，防止别人跑脚本

5分钟内支付啊，未支付就是放弃资格

下单的时候

update goods set stock = stock - 1 where stock - 1 > 0 

@crazy 这个语句是不是会剩最后一个商品谁也拍不走吧

如果抢购成功，就直接让其支付。不支付，就视其放弃抢购，然后加回到库存里去。这样可以避免被人恶意占用库存。

话说没上锁吗，不然怎么会超卖呢，，，

几台服务器？简单描述下架构？ :grin:

1、设定一个较短的时间不付款取消订单，如5分钟

2、在用户下单的时候如果库存为0那么一并返回未付款的人数，合并后返回信息如 “商品已售空, 12人未付款, 请休息一下再抢, 还有机会哦~”

付款成功减少库存，商品库存为1的时候，然后n个人同时付款,最后只有一个人购买成购，还要做自动退款处理 :joy:

我们之前遇到过，用秒杀系统容易超卖，后来改成抢优惠券 :sob:

我想到的方案有两种：

1. 在用户下单的时候，加锁，事务开启，限制好库存，生成订单，然后计时5分钟，如果5分钟内用户不支付，则取消该用户的订单，意思是限制下单数量，不支付的回退，支付的一样要走事务加锁，然后修改。
2. 所有用户可以进行下单，但是在创建秒杀成功的时候需要对应库存，一样事务开启，加锁，意思就是谁先支付就是谁的，我只卖20个。

注意：建议是返回一个秒杀地址，所带参数使用加密算法进行加密（这样可以防止恶意秒杀）

具体实现：

//秒杀逻辑开始
DB::transaction(function ()  {
    $seckill = Seckill::query
        ->lockForUpdate()
        ->findOrFail($id);

    // todo：判断当前用户是否满足秒杀需求

    $user = Auth::guard('api')->user();

   // todo：判断用户是否已秒杀过，判断当前秒杀库存是否足够

    try {
        // 执行用户秒杀逻辑
    } catch (HttpException $httpException) {
        \DB::rollBack();
    };
});

面试题常考的，让你碰到了。

依稀记得疫情期间我项目抢特价蔬菜一下400份秒空还没有用redis限制,,我的居然没超卖...

实际抢购商品的数量和抢购人数相差很大可以直接在前面随机拒绝掉一大波人

我给出的建议是：

1、少卖问题处理： 用户购买生成订单才库存数-1，并返回支付参数给前端，同时设置订单的有效期在1-5分钟之内，如果时间过了库存数+1，因为秒抢的的商品过了5分钟就不会有人抱有希望，所以把握这个点。

2、优化处理：

• 库存数可以用redis 存储，毕竟redis比mysql快
• 已支付的订单数等于总库存数时，才告知用户已售完，其他时候可以设置一个等待的动画，例如小米的动画，让用户等待

nginx 弄炸的，

一样的, 所有的抢购是抢到了就-1, 但是一般都有订单超时自动取消业务的, 你可以使用redis key过期事件来监听订单超时未支付自动取消, 这样把库存加回来

我们一般都是把商品信息, 库存都存到redis中, 这样避免频繁查询mysql, 但是会有很小的概率碰到缓存不一致的问题, 只能隔段时间清次redis, 不知道大家缓存不一致的问题是怎么解决的呢?

【还有3天就不用了，客户没有说必须要改，老板不想改，我不敢改 怕出问题】 老铁在这个公司扮演的是嘛角色 :joy:

既然都用了redis就继续用redis来解决呀。发起付款，减库存。来个超时自动将未付款订单设置为超时。同时释放库存呢。

如果 php-fpm 架构承受不住流量冲击，可以考虑 Swoole 或者 API 网关来进行流量过滤。

比较好奇服务器的配置是什么？

秒杀系统设计，推荐这篇文章：博客：秒杀系统的设计

淘宝京东都是下单锁库存的，看直播经常有踢人释放库存的。

我有个朋友想知道是哪个小程序做特价，顺便提一句，高并发的业务场景少用io操作，比如你用的：config

和我遇到的情况类似，我是做了时间限制，一分半订单过期不能支付，两分钟后执行定时任务取消该订单，增加库存量

学习小米模式-先预约-在发码-在付款 这样就不会有超卖的情况了。。。码都是预先生成和库存一致的

你都说了小项目了，那就别在乎这点了。。。。

我只想说前东家的公司服务器是16核16G的，数据库是4核16G，抢购直接用LockforUpdate都没事