关联阅读

秒杀场景设计的总结

简单列一下分布式高并发要做的事情

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

高并发下热Key解决方案总结

基于SpringBoot和ZK的热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脚本的原子性。代码如下：

--商品Key
local key = KEYS[1]
--购买数
local val = ARGV[1]
--现有总库存
local stock = redis.call("GET", key)
if (tonumber(stock)<=0) 
then
    --没有库存
    print("没有库存")
    return -1
else
    --获取扣减后的总库存=总库存-购买数
    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
    end
end

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

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

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

测试

我使用的是dockey，先把lua脚本上传至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

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

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

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