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

回复之前的误解

之前因为没有将 php-fpm 并发配置调高,导致一堆 502。

后面调高就好了。

一堆瞎操作,原来是没有调整配置….

最后就 60% cpu

小程序: 狮力健 (现在几乎没什么人了 口罩的高峰期过了)

问题产生

某个商品突然说要做秒杀。
秒杀,挺耗费时间了,老板和客户商量,最后改成抢购。

其实就是增加库存功能,然后人工在固定时间改库存,用户抢购。 (哈哈哈 就是这么简单)

活动规则

昨天 ( 5 - 11)

服务器直接炸了,几十秒之内所有项目不能访问。
出现超卖。

在10号才三十几人,没想到11号,马上变成1.2k人,我丢。

我本以为是个小项目,什么限制都没做。
(经历过太多这种小项目了)

11号10点一到,直接炸了,还超卖。

改善

限制: (都要先经过 redis 的限制)

1. 每个人每秒只能访问一次
2. lpop保证不超卖

我以为这样不会炸了。

今天 ( 5 - 12 )

又炸了,但是没有超卖,比昨天好很多,还能访问。
(3秒)

残余问题

少卖

用户发起购买请求,库存-1,返回支付参数给前端。 也就是说: 用户不支付,也会库存-1

本来30个名额的,现在卖了30个,只有20个支付了,10个未支付,所以是少卖了。

我不想用复杂的来写

1. 老板不会ra我花费太多时间来 客户也没有说什么
2. 我怕坑,如果用了队列,还要自己测，测了上线还担心bug

我慢慢想 简单 && 又能解决的办法

为何不在支付成功后再库存-1 ?

除了抢购商品都是这样处理的

抢购商品这样处理的话 逗我吗 ……