超卖问题解决方案

目录

需求概述

系统需求

提升高并发吞吐量

解决超卖问题

解决方案分析

悲观锁与乐观锁

悲观锁

乐观锁

数据库行级锁

实现悲观锁（排他锁）

实现乐观锁

悲观锁&乐观锁

Redis分布式锁

Redis原子操作方案

方案分析

技术实现

通过MULTI事务命令实现

Redis+Lua实现

使用Lua注意点

---

需求概述

系统需求

在本项目的抢卷模块中需要实现下边两个需求

提升高并发吞吐量

抢卷类似抢购、秒杀等业务场景，具有时效性的特点，提前规定好用户在什么时间可以抢购，用户访问集中，这样就会给系统造成高并发，抢卷模块在设计时需要以提升系统在高并发下的吞吐量为目标（吞吐量表示单位时间内系统处理的总请求数量，吞吐量高意味着系统处理能力强

衡量系统吞吐量的常用指标：QPS，TPS

QPS（Queries Per Second）：

每秒查询数（Queries Per Second），它表示系统在每秒内 能够处理的查询或请求的数量，是衡量一个系统处理请求的性能和吞吐量的指标。

计算公式：总请求数/时间窗口大小

示例：

在10秒内处理1万个请求，QPS为1000。每个请求处理的时间越短，QPS越大。

假设：一个网站有10万用户，有2万日活跃用户，并发量是4000，每个用户每秒平均发起2个请求，那么总请求数就是 2*4000，那么QPS就是 8000，如果单机支持2000的qps理论上需要4台服务器。

qps指标是需要根据服务器硬件性能、及具体的业务场景去测试，比如：门户查询数据如果直接走Nginx静态服务器则QPS可以达到上万，如果请求查询Tomcat，并且通过数据库去查询数据库返回，此时QPS会远低于查询Nginx静态服务器的QPS值，如果不走数据库,而是从Redis查询数其QPS也会大大提升。

TPS（Transactions Per Second）：

表示系统每秒完成的事务数，与QPS不同，TPS更关注系统的事务处理能力，而不仅仅是单纯的查询或请求，一次事务通常会包括多个请求。在高度事务性的系统中，如在线交易系统、支付系统等，TPS是一个关键指标，用于衡量系统的处理能力。

TPS指标通常会涉及业务处理及数据库存储，在测试时也需要根据服务器硬件性能、及具体的业务场景去测试，拿下单举例：单机支持几十到几百的TPS指标属于正常。

解决超卖问题

超卖是最终下单购买数量大于库存数量，比如：库存有１00个，用户最终购买了101个，多出这一个就是超卖了，结合抢券业务即用户最终抢到的优惠券总数大于优惠券库存数。

造成超卖的原因：造成超卖问题的原因是在高并发场景下对库存这个共享资源进行操作存在线程不安全所导致

举例：

下图是两个线程更新数据库的库存字段。

线程1：先查询库存为1，判断是否大于0，如果大于则库存减1，最后更新数据库库存字段

线程2：先查询库存为1，判断是否大于0，如果大于则库存减1，最后更新数据库库存字段

线程1和线程2查询到的库存都是1，两个线程分别减1得到剩余库存数为0，由于线程2并不是基于线程1扣减库存后的值进行扣减，线程2更新库存覆盖了线程1更新的库存值，最后的库存都为0，但是却执行了两次卖出操作，因此出现了超卖问题。

解决方案分析

悲观锁与乐观锁

悲观锁

悲观锁是一种悲观思想，总是认为会有其他线程修改数据库，为了保证线程安全，因此在操作前总是先加锁，操作完成后释放锁，其他线程只有当锁释放后才可以获取锁继续操作数据。synchronized和ReentrantLock都可以实现悲观锁

使用悲观锁后，原来的多线程并发执行改为了顺序（同步）执行，当线程2去执行时查询到库存发现为0，不满足条件更新库存失败

乐观锁

乐观锁是一种乐观思想，认为不会有太多线程去并发修改数据，所以谁都可以去执行代码

Java提供的CAS机制可以实现乐观锁，CAS（Compare And Swap，比较并交换），在修改数据前比较版本号，如果数据的版本号骄傲没有变化说明书菊没有修改，此时再去修改数据

示例：

库存数据对应一个版本，库存每次变化则版本号跟着变化，如下：

库存	版本号
100	1
99	2
...	...
1	100
0	101

线程1修改库存前拿到库存及对应的版本号：1和100。

线程1判断库存如果大于0则将库存减1，准备更新库存。

更新库存时要校验当前库存的版本是否和自己之前拿到的一致，如果版本号为1说明自己在执行的这过程没有其它线程去修改过库存，此时将库存更新为99并将库存加1为2。

线程2执行和线程1一样的逻辑，线程2去更新库存时发现库存的版本号为2与自己之前拿到的不一致，更新库存失败。

数据库行级锁

实现悲观锁（排他锁）

执行select ... for update实现加锁，select ... for update会锁住符合条件的行的数据，如下语句会锁住一行的数据：

select * from 库存表 where id=? for update

通常此语句放在事务中，开启事务时执行此语句获取锁，事务提交或回滚自动释放锁，保证在事务处理过程中没有其他线程去修改数据。

高并发场景不推荐使用select … for update方法，同时也可能存在死锁的潜在风险。

实现乐观锁

数据库行级锁也可以实现乐观锁，通常做法是在表中添加一个version字段，在更新时对比版本号，更新成功将版本号加1，SQL为：

update 表名 set 字段=值,version=version+1 where  id =? and version =?

针对扣减库存业务：

update 库存表 set 库存=库存-1 where 库存>0 and id =?

多线程执行上面的SQL，假如线程1先执行会添加排他锁，当事务没有结束前其他线程去更新同一条记录会被阻塞，等到线程1更新结束其他线程才可以更新库存

当执行update后返回影响的记录行数为1，表示更新成功即扣减库存成功，返回0表示没有更新记录行，即扣减库存失败

悲观锁&乐观锁

悲观锁和乐观锁都是一种解决共享资源的线程安全问题的方法，悲观锁是在读数据时就加锁，如果读比较多则加锁频繁影响性能，相比而言乐观锁性能比悲观锁要好。

对于并发不高的场景可以使用数据乐观锁去控制扣减库存，由于抢购业务并发较高且对性能要求也高，如果使用数据库行级锁去控制，并发高就会对数据造成压力，如果进行限流控制并发数又无法满足性能要求，所以对于抢购业务使用数据库行级锁进行控制是不合适的

Redis分布式锁

数据库乐观锁不适合用高并发场景，可以将库存数据放在Redis，并且通过JVM锁区控制扣减库存

上边介绍的synchronized、reentrantLock、CAS只控制了JVM本身的线程争抢同一个锁，无法控制多个JVM之间争抢同一个锁。

如下图，有两个JVM进程，每个JVM进程都有一个Lock01锁，这两个JVM进程中的线程1仍然会同时去修改库存：

线程1：先查询库存为1，判断是否大于0，如果大于则库存减1，最后更新Redis库存数据。

线程2：先查询库存为1，判断是否大于0，如果大于则库存减1，最后更新Redis库存数据。

此时就会出现修改库存数据的线程不安全问题。

所以，如果是单机环境下，使用JVM的锁在内存加锁可以解决资源并发访问的线程安全问题。

微服务架构的项目在部署时，每个微服务会部署多个实例（每个JVM就是一个实例），如果要控制多个JVM之间争抢资源需要用到分布式锁，分布式锁是由一个统一的服务提供分布式锁服务，例如Redis等数据库可以实现分布式锁。

如下图，每个JVM中的线程取证强同一个分布式锁，在扣减库存前先获取分布式锁，拿到锁再扣减库存，执行完释放锁之后其他的JVM的线程才可以获取锁继续扣减库存，如下图：

上述方案将库存放在Redis中避免了与数据库交互，很大程度上提高了执行效率，在分布式场景下使用分布式锁是一种常用的控制共享资源的方案

分布式锁需要搭建独立的分布式锁服务（例如Redis、Zookeeper等），每次操作需要远程与分布式锁服务交互获取锁、释放锁。

Redis原子操作方案

上边使用分布式锁的方案中，每次操作需要远程与分布式锁服务交互获取锁、释放锁，在这个过程中申请锁和释放锁的交互操作在一定程度上会损耗服务器的性能，因此我们尝试将锁的交互进行优化

分布式锁方案中是在Java程序扣减库存最后更新redis库存的值，可以使用redis的decr命令去扣减库存

（Redis Decr命令将key中储存的数字值减1，并且具有原子性，Redis中所有命令都具有原子性

原子性表示该命令在执行过程中是不被中断的，也就实现了多线程去执行decr命令扣减库存是顺序执行的，加入库存原来是100，扣减到0结束，多线程并发执行decr命令不会出现扣减次数超过100次，如下图：

基于Redis命令的原子性，我们将JVM锁的交互转移到Redis数据库中进行处理：

方案分析

在Redis原子操作方案中扣减库存使用decr命令实现，decr命令具有原子性，如果在扣减库存操作中有多个操作，那么操作不再是原子性：

扣减库存逻辑如下：

1、首先查询库存

2、判断库存大小，如果大于0则扣减库存，否则 直接返回

3、记录抢券成功的记录，用于判断用户不能重复抢券的依据。

4、记录抢券同步的记录，用于后续的异步处理，将抢券结果保存到数据库。

如果上述四步整体不具有原子性仍然没有办法控制超卖问题，所以必须保证1、2、3步逻辑放在一起整体具有原子性。

因此需要我们保证多个Redis命令具有原子性

技术实现

对于redis单个命令都是原子操作，现在要求扣减库存、写入抢卷成功队列及写入同步队列保证原子性，有两个解决方案：通过MULTI事务命令实现、Redis+Lua实现

通过MULTI事务命令实现

MULTI
HSET key1 field1 value2 field2 value2
INCR key2
EXEC

命令执行流程如下：

执行MULTI 标记首先标记一个事务块开始。

然后将要执行的命令加入队列。

将“HSET key1 field1 value2 field2 value2” 命令放入队列中，表示向key1中写入两个hashkey。

将“INCR key2”命令放入队列中，表示对key2自增1。

运行EXEC命令按顺序执行，整体保证原子性。

Pipeline与MULTI区别

pipline也可实现批量执行多个 redis命令，pipline与multi的区别是：

pipeline 是把多个redis指令一起发出去，redis并没有保证这些命令的执行是原子的；multi实现的是将多个命令作为事务块去执行，保证整个操作的原子性。

如果仅是执行多个命令不保证原子性那么使用pipeline 的性能要比multi要高，但是针对本项目要保证多个命令实现原子性的需求那么pipeline 不符合要求。

Redis+Lua实现

Lua 是一种强大、高效、轻量级、可嵌入的脚本语言，Lua体积小、启动速度快，从而适合嵌入在别的程序里，Lua可以用于web开发、游戏开发、嵌入式开发等领域。

参考：http://www.lua.org/docs.html

对上边的例子编写Lua脚本，如下：

local ret = redis.call('hset', KEYS[1], ARGV[1], ARGV[2], ARGV[3], ARGV[4]);
redis.call('incr', KEYS[2]);
return ret..'';

说明：

KEYS：表示在脚本中所用到的那些Redis键（key），这些键名参数可以在Lua中通过全局变量KEYS数组，KEYS[1]表示第一个key，KEYS[2]表示第二个key...

ARGV：表示在脚本中所用到的参数，在Lua主功能通过全局变量ARGV数组访问，访问形式和KEYS变量类似（ARGV[1]、ARGV[2]，诸如此类），ARGV[1]、ARGV[2]分别表示第一个第二个参数。。

执行Lua脚本：

使用EVAL 命令执行Lua脚本。

EVAL是redis的命令本身具有原子性，整个脚本的执行具有原子性。

EVAL script numkeys key [key ...] arg [arg ...]

参数说明：

• script： 是一段 Lua 5.1 脚本程序。
• numkeys： 用于指定键名参数的个数。
• key [key ...]： 从 EVAL 的第三个参数开始算起，表示在脚本中所用到的那些 Redis 键(key)，这些键名参数可以在 Lua 中通过全局变量 KEYS 数组，用 1 为基址的形式访问( KEYS[1] ， KEYS[2] ，以此类推)。
• arg [arg ...]： 附加参数，在 Lua 中通过全局变量 ARGV 数组访问，访问的形式和 KEYS 变量类似( ARGV[1] 、 ARGV[2] ，诸如此类)。

eval "local ret = redis.call('hset', KEYS[1], ARGV[1], ARGV[2], ARGV[3], ARGV[4]);redis.call('incr', KEYS[2]);return ret..'';" 2 test_key01 test_key02 field1 aa field2 bb

说明：

eval后边的script参数即脚本程序，将上边的Lua脚本使用双引号括起来。

numkeys：为2表示2个key

之后传入key的名称（多key中间用空格分隔）：test_key01 test_key02

key后边再传入ARGV 参数（多ARGV 中间用空格分隔）：field1 aa field2 bb

Java代码中调用Lua脚本：

指定Lua脚本的位置，通过DefaultRedisScript的setScriptSource方法完成：

在RedisLuaConfiguration中定义DefaultRedisScript bean：

@Bean("Lua_test01")
public DefaultRedisScript<Integer> getLuaTest01() {DefaultRedisScript<Integer> redisScript = new DefaultRedisScript<>();//resource目录下的scripts文件下的Lua_test01.Lua文件redisScript.setScriptSource(new ResourceScriptSource(new ClassPathResource("scripts/Lua_test01.Lua")));redisScript.setResultType(Integer.class);return redisScript;
}

创建lua脚本 ：~~

创建RedisTest测试类:

注入上边定义的DefaultRedisScript，注意注入时指定名称“Lua_test01”。

package com.jzo2o.market.service;import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;import javax.annotation.Resource;
import java.util.Arrays;
import java.util.List;@SpringBootTest
@Slf4j
public class RedisLuaTest {@Resource(name = "redisTemplate")RedisTemplate redisTemplate;@Resource(name = "Lua_test01")DefaultRedisScript script;//测试Lua@Testpublic void test_Luafirst() {//参数1：key ,key1:test_key01  key2:test_key02List<String> keys = Arrays.asList("test_key01","test_key02");//参数2：传入Lua脚本的参数,"field1","aa","field2", "bb"Object result = redisTemplate.execute(script, keys, "field1","aa","field2", "bb");log.info("执行结果:{}",result);}}

MULTI 不适合写带有业务逻辑的脚本内容，并且MULTI 执行命令是执行完成最后一起拿到所有命令的执行结果，业务中有一些逻辑判断，可能需要提前返回结果，因此我们使用Redis+Lua实现抢卷功能

抢卷功能的Lua脚本如下：

-- 抢券Lua实现
-- key: 抢券同步队列，资源库存,抢券成功列表
-- argv：活动id,用户id--优惠券是否已经抢过
local couponNum = redis.call("HGET", KEYS[3], ARGV[2])
-- hget 获取不到数据返回false而不是nil
if couponNum ~= false and tonumber(couponNum) >= 1
thenreturn "-1";
end
-- --库存是否充足校验
local stockNum = redis.call("HGET",KEYS[2], ARGV[1])
if stockNum == false or  tonumber(stockNum) < 1
thenreturn "-2";
end
--抢券列表
local listNum = redis.call("HSET",KEYS[3], ARGV[2], 1)
if listNum == false or  tonumber(listNum) < 1
thenreturn "-3";
end--减库存
stockNum = redis.call("HINCRBY",KEYS[2], ARGV[1], -1)
if tonumber(stockNum) < 0
thenreturn "-4"
end
-- 抢单结果写入同步队列
local result = redis.call("HSETNX", KEYS[1], ARGV[2],ARGV[1])
if result > 0
thenreturn ARGV[1] ..""
end
return "-5"

使用Lua注意点

Lua脚本在redis集群上执行需要注意什么？

在redis集群下执行redis命令会根据key求哈希，确定具体的槽位（slot），然后将命令路由到负责该槽位的 Redis 节点上。

执行一次Lua脚本会涉及到多个key，在redis集群下执行lua脚本要求多个key必须最终落到同一个节点，否则调用Lua脚本会报错：ERR eval/evalsha command keys must be in same slot。

如何保证多个key落地到一个redis节点呢？

只要保证多个key的哈希值一致即可保证多个key落到一个redis节点上，这个如何实现呢？

解决方法：一次执行Lua脚本的所有key中使用大括号‘{}’且保证大括号中的内容相同，此时会根据大括号中的内容求哈希，因为内容相同所以求得的哈希数据相同所以就落在了同一个Redis节点。

测试如下：

在key名称后边添加{}，大括号中写一个固定的值。

@Test
public void test_Luafirst2() {//参数1：key ,key1:test_key01List<String> keys = Arrays.asList("test_key01{111}","test_key02{111}");//参数2：传入Lua脚本的参数,"field1","aa","field2", "bb"Object result = redisTemplate.execute(script, keys, "field1","aa","field2", "bb");log.info("执行结果:{}",result);
}