vlambda博客
学习文章列表

高并发秒杀场景下,基于Redis、LUA防止商品超卖

关联阅读



与超卖对应的是商品热Key的解决方案



高并发情况下,库存扣减、查询等操作就不要考虑用数据库了,Redis是比较常用的解决方案,主要是基于Redis的高并发、原子性的特点。


防止用户重复提交购买

如果前端的“购买”按钮没有置灰,用户可能会反复点击,或者有的用户用软件去刷单,可以使用限流、分布式锁等方式来限制用户的请求。

以分布式锁为例,可以使用“用户ID+排序后的商品ID:购买数量”为Key,例如userId999-spuId111:10-spuId222:10。

但如果用户发N个请求,每个请求的商品ID、购买数量都不一样,或者用户在多客户端发起对不同商品的购买,则这种锁就被绕过。

如果要求严格的话,可以直接锁用户,这样会使客户无法在多客户端进行购买。

按照业务要求进行处理吧。


防止超卖

分两种情况:

一、一次只允许购买一个

使用Redis的List。假设有10个库存,则list插入10个1,购买的时候,使用lpop或rpop取出一个元素,如果为1,则说明有货,执行购买流程,如果为nil说明无货,直接返回。

如果要求一个用户只能购买一次,则需要搭配Redis的Set,通过sadd插入用户ID,如果用户没有购买记录,则sadd返回值为1,否则为0。

二、允许购买多个

步骤如下:

1、先查库存,如果库存-购买数<0,则说明用户购买的数量大于库存,返回失败。否则执行扣减库存流程。

2、使用"decrby key 购买数",扣减库存,返回成功。

按照上述步骤会出现以下情况:

A、用户甲购买时,步骤1,2之间无其他操作,顺利抢购成功,返回的库存数必>=0。

B、用户甲购买时,步骤1,2之间,用户乙抢先扣了库存,导致用户甲再扣库存时,超卖了。

流程示意:

甲查询库存10,购买数5,通过-->

乙查询库存10,购买数6,通过-->

乙扣减库存数6,现有库存4-->

甲扣减库存数5,现有库存数-1,导致超卖。

所以AB两个步骤的操作万不可使用程序来处理,而应该使用LUA脚本,Redis保证了执行LUA脚本的原子性。代码如下:

--商品KEYlocal key = KEYS[1]--购买数local val = ARGV[1]--现有总库存local stock = redis.call("GET", key)if (tonumber(stock)<=0) then --没有库存 print("没有库存") return -1else --获取扣减后的总库存=总库存-购买数 local decrstock=redis.call("DECRBY", key, val) if(tonumber(decrstock)>=0) then --扣减购买数后没有超卖,返回现库存 print("没有超卖,现有库存数"..decrstock) return decrstock else --超卖了,把扣减的再加回去 redis.call("INCRBY", key, val) print("超卖了,现有库存"..stock.."不够购买数"..val) return -2 endend

因为我也没系统学过LUA语言,今天也是一边查资料一边写脚本,有几个地方记录一下:

1、Redis存的是数字,但取出来的是String,所以比较数字的时候用tonumber()转一下。

2、print的连接符是..不是+


测试

我使用的是Docker,要先把脚本上传

docker cp /本机目录/decrby.lua 容器ID:/data

先预热商品库存,库存数100

set spu 100

执行扣减脚本,购买数50,结果应返回50,再get应该是50

redis-cli --eval decrby.lua spu , 50

注意:key、value两处,前后要有空格。

结果如下:

执行扣减脚本,购买数51,结果应返回-2,再get应该还是50

结果如下:

高并发秒杀场景下,基于Redis、LUA防止商品超卖

执行扣减脚本,购买数50,结果应返回0,再get应该为0

结果如下:

执行扣减脚本,购买数5,结果应返回-1,再get应该为0

结果如下:

在实际工作中,如果我们使用Spring Boot的RedisTemplate,这段脚本可以声明为静态String。