Redis解决秒杀微服务抢购代金券超卖和同一个用户多次抢购_超卖 redis

最新推荐文章于 2024-09-30 11:23:38 发布
最新推荐文章于 2024-09-30 11:23:38 发布
阅读量903 收藏 15
点赞数 27
分类专栏： 程序员 文章标签： redis 微服务 oracle
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_84254296/article/details/137713403
版权
本文介绍了在高并发环境下如何通过Redis实现分布式锁和lua脚本避免库存超卖问题，包括修改数据库操作以与Redis交互，使用Lua脚本确保库存操作的原子性，并详细展示了改造后的抢购代金券逻辑和下单逻辑。
摘要由CSDN通过智能技术生成

Date now = new Date();
AssertUtil.isTrue(now.before(seckillVouchers.getStartTime()), “该抢购还未开始”);
AssertUtil.isTrue(now.after(seckillVouchers.getEndTime()), “该抢购已结束”);
// 判断是否卖完
AssertUtil.isTrue(seckillVouchers.getAmount() < 1, “该券已经卖完了”);
// 获取登录用户信息
String url = oauthServerName + “user/me?access_token={accessToken}”;
ResultInfo resultInfo = restTemplate.getForObject(url, ResultInfo.class, accessToken);
if (resultInfo.getCode() != ApiConstant.SUCCESS_CODE) {
resultInfo.setPath(path);
return resultInfo;
}
// 这里的data是一个LinkedHashMap，SignInDinerInfo
SignInDinerInfo dinerInfo = BeanUtil.fillBeanWithMap((LinkedHashMap) resultInfo.getData(),
new SignInDinerInfo(), false);
// 判断登录用户是否已抢到(一个用户针对这次活动只能买一次)
VoucherOrders order = voucherOrdersMapper.findDinerOrder(dinerInfo.getId(),
seckillVouchers.getId());
AssertUtil.isTrue(order != null, “该用户已抢到该代金券，无需再抢”);
// 扣库存
int count = seckillVouchersMapper.stockDecrease(seckillVouchers.getId());
AssertUtil.isTrue(count == 0, “该券已经卖完了”);
// 下单
VoucherOrders voucherOrders = new VoucherOrders();
voucherOrders.setFkDinerId(dinerInfo.getId());
voucherOrders.setFkSeckillId(seckillVouchers.getId());
voucherOrders.setFkVoucherId(seckillVouchers.getFkVoucherId());
String orderNo = IdUtil.getSnowflake(1, 1).nextIdStr();
voucherOrders.setOrderNo(orderNo);
voucherOrders.setOrderType(1);
voucherOrders.setStatus(0);
count = voucherOrdersMapper.save(voucherOrders);
AssertUtil.isTrue(count == 0, “用户抢购失败”);

return ResultInfoUtil.buildSuccess(path, “抢购成功”);
}

在这里插入图片描述
高并发环境下会导致上图的判断出现错误。在高并发环境下，会有多个线程拿到的库存值都大于0，实际的继续往下执行的线程会高于实际的库存值，继续执行会导致卖出的订单量超过库存本身的数量，导致库存超卖。
image.png
同理同一用户多次发起，同时到达这一步也会错判，在还没有获取到最新的存储结果时，都会判定成是未抢购过，导致同一用户可以重复抢购问题。

解决库存超卖问题

添加相关枚举

在redis键的枚举类中添加如下枚举：
image.png
分布式锁的key来约束同一用户只能抢购一次。

添加RedisTemplate配置类

/**
* RedisTemplate配置类
* @author zjq
*/
@Configuration
public class RedisTemplateConfiguration {

/**
* redisTemplate 序列化使用的jdkSerializeable, 存储二进制字节码, 所以自定义序列化类
*
* @param redisConnectionFactory
* @return
*/
@Bean
public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
RedisTemplate<Object, Object> redisTemplate = new RedisTemplate<>();
redisTemplate.setConnectionFactory(redisConnectionFactory);

// 使用Jackson2JsonRedisSerialize 替换默认序列化
Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
jackson2JsonRedisSerializer.setObjectMapper(objectMapper);

// 设置key和value的序列化规则
redisTemplate.setValueSerializer(jackson2JsonRedisSerializer);
redisTemplate.setKeySerializer(new StringRedisSerializer());

redisTemplate.setHashKeySerializer(new StringRedisSerializer());
redisTemplate.setHashValueSerializer(jackson2JsonRedisSerializer);

redisTemplate.afterPropertiesSet();
return redisTemplate;
}

@Bean
public DefaultRedisScript stockScript() {
DefaultRedisScript redisScript = new DefaultRedisScript<>();
//放在和application.yml 同层目录下
redisScript.setLocation(new ClassPathResource(“stock.lua”));
redisScript.setResultType(Long.class);
return redisScript;
}

}

改造原先添加代金券逻辑

原先添加代金券的逻辑如下：
在这里插入图片描述

现在需要把跟数据库交互的部分改成和redis交互，改造后代码如下：

// 采用 Redis 实现
String key = RedisKeyConstant.seckill_vouchers.getKey() +
seckillVouchers.getFkVoucherId();
// 验证 Redis 中是否已经存在该券的秒杀活动
Map<String, Object> map = redisTemplate.opsForHash().entries(key);
AssertUtil.isTrue(!map.isEmpty() && (int) map.get(“amount”) > 0, “该券已经拥有了抢购活动”);

// 插入 Redis
seckillVouchers.setIsValid(1);
seckillVouchers.setCreateDate(now);
seckillVouchers.setUpdateDate(now);
redisTemplate.opsForHash().putAll(key, BeanUtil.beanToMap(seckillVouchers));

执行测试，新建秒杀代金券活动存储到Redis中：
image.png
在这里插入图片描述
可以看到数据已经存储到redis中。

改造下单逻辑
调整数据库相关为redis

原先关系型数据库下单逻辑：

/**
* 抢购代金券
*
* @param voucherId 代金券 ID
* @param accessToken 登录token
* @Para path 访问路径
*/
public ResultInfo doSeckill(Integer voucherId, String accessToken, String path) {
// 基本参数校验
AssertUtil.isTrue(voucherId == null || voucherId < 0, “请选择需要抢购的代金券”);
AssertUtil.isNotEmpty(accessToken, “请登录”);
// 判断此代金券是否加入抢购
SeckillVouchers seckillVouchers = seckillVouchersMapper.selectVoucher(voucherId);
AssertUtil.isTrue(seckillVouchers == null, “该代金券并未有抢购活动”);
// 判断是否有效
AssertUtil.isTrue(seckillVouchers.getIsValid() == 0, “该活动已结束”);
// 判断是否开始、结束
Date now = new Date();
AssertUtil.isTrue(now.before(seckillVouchers.getStartTime()), “该抢购还未开始”);
AssertUtil.isTrue(now.after(seckillVouchers.getEndTime()), “该抢购已结束”);
// 判断是否卖完
AssertUtil.isTrue(seckillVouchers.getAmount() < 1, “该券已经卖完了”);
// 获取登录用户信息
String url = oauthServerName + “user/me?access_token={accessToken}”;
ResultInfo resultInfo = restTemplate.getForObject(url, ResultInfo.class, accessToken);
if (resultInfo.getCode() != ApiConstant.SUCCESS_CODE) {
resultInfo.setPath(path);
return resultInfo;
}
// 这里的data是一个LinkedHashMap，SignInDinerInfo
SignInDinerInfo dinerInfo = BeanUtil.fillBeanWithMap((LinkedHashMap) resultInfo.getData(),
new SignInDinerInfo(), false);
// 判断登录用户是否已抢到(一个用户针对这次活动只能买一次)
VoucherOrders order = voucherOrdersMapper.findDinerOrder(dinerInfo.getId(),
seckillVouchers.getId());
AssertUtil.isTrue(order != null, “该用户已抢到该代金券，无需再抢”);
// 扣库存
int count = seckillVouchersMapper.stockDecrease(seckillVouchers.getId());
AssertUtil.isTrue(count == 0, “该券已经卖完了”);
// 下单
VoucherOrders voucherOrders = new VoucherOrders();
voucherOrders.setFkDinerId(dinerInfo.getId());
voucherOrders.setFkSeckillId(seckillVouchers.getId());
voucherOrders.setFkVoucherId(seckillVouchers.getFkVoucherId());
String orderNo = IdUtil.getSnowflake(1, 1).nextIdStr();
voucherOrders.setOrderNo(orderNo);
voucherOrders.setOrderType(1);
voucherOrders.setStatus(0);
count = voucherOrdersMapper.save(voucherOrders);
AssertUtil.isTrue(count == 0, “用户抢购失败”);

return ResultInfoUtil.buildSuccess(path, “抢购成功”);
}

查询、扣库存和下单逻辑调整成Redis：
image.png

// 扣库存 redis没有自减方法，数值传负数表示自减
long count = redisTemplate.opsForHash().increment(key, “amount”, -1);
AssertUtil.isTrue(count <= 0, “该券已经卖完了”);

订单信息还是保存到数据库中

// 下单
VoucherOrders voucherOrders = new VoucherOrders();
voucherOrders.setFkDinerId(dinerInfo.getId());
//redis中不需要维护该外键信息
// voucherOrders.setFkSeckillId(seckillVouchers.getId());
voucherOrders.setFkVoucherId(seckillVouchers.getFkVoucherId());
String orderNo = IdUtil.getSnowflake(1, 1).nextIdStr();
voucherOrders.setOrderNo(orderNo);
voucherOrders.setOrderType(1);
voucherOrders.setStatus(0);
count = voucherOrdersMapper.save(voucherOrders);

JMeter发起3000个线程，2000个用户并发请求，查看库存情况，目前还是超卖的：
在这里插入图片描述
订单的数量是正确的：
image.png
因为这一步判定是单线程的

long count = redisTemplate.opsForHash().increment(key, “amount”, -1);
AssertUtil.isTrue(count <= 0, “该券已经卖完了”);

是不是先下单然后再扣库存就可以了？当然不行，如果上面位置调整下会导致库存数量不对，订单数量也不对😰😰😰。
我们继续在先下单后扣库存的方法上添加一个事务：@Transactional(rollbackFor = Exception.class)。
执行发现订单数量正常了，库存还是负数：
image.png
为什么会有这个问题呢，因为redisTemplate.opsForHash().increment(key, "amount", -1)这一步操作在redis中实际执行的是先查询再减少的操作，在高并发场景下会有问题。我们需要保证这两步的原子性。

Redis + Lua 解决超卖问题

在yml配置文件同级目录添加lua脚本，脚本内容如下：

if (redis.call(‘hexists’, KEYS[1], KEYS[2]) == 1) then
local stock = tonumber(redis.call(‘hget’, KEYS[1], KEYS[2]));
if (stock > 0) then
redis.call(‘hincrby’, KEYS[1], KEYS[2], -1);
return stock;
end;
return 0;
end;

在RedisTemplate配置类中添加如下配置bean并注入lua脚本：

@Bean
public DefaultRedisScript stockScript() {
DefaultRedisScript redisScript = new DefaultRedisScript<>();
//放在和application.yml 同层目录下
redisScript.setLocation(new ClassPathResource(“stock.lua”));
redisScript.setResultType(Long.class);
return redisScript;
}

扣库存逻辑调整如下：

// 采用 Redis + Lua 解决超卖问题
// 扣库存
List keys = new ArrayList<>();
keys.add(key);
keys.add(“amount”);
Long amount = (Long) redisTemplate.execute(defaultRedisScript, keys);
AssertUtil.isTrue(amount == null || amount < 1, “该券已经卖完了”);

image.png
image.png

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
img
img
img
img
img

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）
img

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！**

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-Hxxt28IN-1712985910385)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

2401_84254296
关注
专栏目录
基于SpringBoot + MySQL + Redis + RabbitMQ + Guava开发的高并发商品限时秒杀系统
06-13
基于SpringBoot + MySQL + Redis + RabbitMQ + Guava开发的高并发商品限时秒杀系统 项目经过严格测试，确保可以运行！源码无需做任何更改！ 系统介绍 本系统是使用SpringBoot开发的高并发限时抢购秒杀系统，除了实现基本的登录、查看商品列表、秒杀、下单等功能，项目中还针对高并发情况实现了系统缓存、降级和限流。 开发工具 IntelliJ IDEA + Navicat + Sublime Text3 + Git + Chrome 压测工具 JMeter 开发技术 前端技术 ：Bootstrap + jQuery + Thymeleaf 后端技术 ：SpringBoot + MyBatis + MySQL 中间件技术 : Druid + Redis + RabbitMQ + Guava 秒杀优化方向 将请求尽量拦截在系统上游：传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小，我们可以通过限流、降级等措施来最大化减少对数据库的访问，从而保护系统。 充分利用缓存：
使用Redis实现分布式锁解决商品超卖问题
m0_54187478的博客
10-20 1257
使用Redis实现分布式锁是一种有效的方式来管理并发访问共享资源。Redis提供了原子性的操作，特别适合用于构建分布式锁。在这种锁的设计中，每个请求都尝试获取锁，只有一个请求成功，其他请求被阻塞。利用Redis的SETNX（SET if Not eXists）命令，可以确保锁的原子性，从而避免竞争条件。这种分布式锁的优点包括快速响应、可靠性和简单性。但需要注意的是，为了避免死锁，锁应该具有超时机制，以确保即使持有锁的客户端崩溃，锁最终会被释放。
在Redis中秒杀场景下超时与超卖问题的解决方案
h123456789999999的博客
05-23 5369
redis高并发场景下秒杀问题的解决方案
Redis解决秒杀微服务抢购代金券超卖和同一个用户多次抢购
write less , do more
12-01 6438
上图就是redission官方网站首页。首页可以看出来，Redisson可以实现很多东西,在Redis的基础上,Redisson做了超多的封装,我们看一下,例如说Spring Cache,TomcatSession,Spring Session,可排序的Set,还有呢Sortedsort,下面还有各种队列,包括这种双端。
Redis解决秒杀微服务抢购代金券超卖和同一个用户多次抢购_超卖 redis(1)
2401_84254296的博客
04-13 933
学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！**
秒杀微服务实现抢购代金券功能
write less , do more
11-27 8822
现在日常购物或者餐饮消费，商家经常会有推出代金券功能，有些时候代金券的数量不多是需要抢购的，那么怎么设计可以保证代金券的消耗量和秒杀到的用户保持一致呢？怎么设计可以保证一个用户只能秒杀到一张代金券呢？秒杀场景有以下几个特点：秒杀场景的应对，一般要从以下几个方面进行处理，如下：本文以抢购代金券为例，来进行数据库表的设计。 抢购活动表 订单表 创建秒杀服务 pom依赖 引入相关依赖如下： 配置文件 关系型数据库实现代金券秒杀 相关实体引入 抢购代金券活动信息 全局异常处理 添加代金券秒杀活动 代金券活
Redis实战 - 04 Redis 分布式锁应用之抢购代金券
你今天真好看呀
10-05 2397
2. 抢购活动表 3. 订单表 2. 秒杀场景的解决方案 秒杀场景有以下几个特点：大量用户同时进行抢购操作，系统流量激增，服务器瞬时压力很大；请求数量远大于商品库存量，只有少数客户可以成功抢购；业务流程不复杂，核心功能是下订单。秒杀场景的应对，一般要从以下几个方面进行处理，如下：① 限流：从客户端层面考虑，限制单个客户抢购频率；服务端层面，加强校验，识别请求是否来源于真实的客户端，并限制请求频率，防止恶意刷单；应用层面，可以使用漏桶算法或令牌桶算法实现应用级限流。② 缓存：热点数据都从缓存获得，尽可能减
Redis的优惠券秒杀问题（六）超卖问题、一人一单问题
金鳞踏雨
11-18 2254
Redis的优惠券秒杀问题之超卖问题、一人一单问题！！！超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁！！！所以我们现在要研究是就是要加什么类型的锁？要怎么加锁？在哪里加锁？什么是一人一单问题？简单的来说就是模拟为了防止黄牛”屯“货而设计的，每一个用户ID，只能下一单！如下图，同一个用户下了很多单！！！这里使用”悲观锁"来实现！
Redis实战——优惠券秒杀：超卖问题&一人一单问题
不愿意做鱼的小鲸鱼の博客
03-18 750
在各类购物App中，都会遇到商家发放的优惠券，当用户抢购商品时，生成的订单会保存到tb_voucher_order表中，而订单表如果使用数据库自增ID就会存在一些问题 * id规律性太明显 * 受单表数据量的限制 * 如果我们的订单id有太明显的规律，那么对于用户或者竞争对手，就很容易猜测出我们的一些敏感信息，例如商城一天之内能卖出多少单，这明显不合适
ZhiyuSun#geektime#02_Redis高阶类型与高阶应用1
07-25
Redis高阶类型与高阶应用代金券表设计限流，缓存，异步，分流压力测试下载windows版建立测试计划5000个线程，2000个用户，出现超卖10000个线程，
Redis：原理速成+项目实战——Redis实战7（优惠券秒杀+细节解决超卖、一人一单问题）
m0_52380556的博客
01-07 1502
Redis：原理速成+项目实战——Redis实战7（优惠券秒杀+细节解决超卖、一人一单问题）
2024年最新《Redis实战篇》三、优惠券秒杀(2)
kOS0ym的博客
05-03 102
时间戳：31bit，以秒为单位，可以使用69年序列号：32bit，秒内的计数器，支持每秒产生2^32个不同ID。
【Redis】Redis实战：黑马点评之优惠券秒杀
qq_50675319的博客
09-19 1356
每个店铺都可以发布优惠券：当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：id的规律性太明显如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。受单表数据量的限制。
Redis实战(黑马点评) 秒杀优惠券优化
m0_59166421的博客
09-22 155
当用户发起请求，此时会请求nginx，nginx会访问到tomcat，而tomcat中的程序，会进行串行操作，分成如下几个步骤1、查询优惠卷2、判断秒杀库存是否足够3、查询订单4、校验是否是一人一单5、扣减库存6、创建订单之前的方案都是基于单线程去操作所有的操作都是一个线程串联执行这就导致了程序的执行的效率。
Redis 基础 - 优惠券秒杀《非集群》
PurineKing之博客
05-20 474
参考 Redis基础 - 基本类型及常用命令 Redis基础 - Java客户端 Redis 基础 - 短信验证码登录 Redis 基础 - 用Redis查询商户信息 摘要 用Redis生成保证唯一性的订单id 代码示例1~代码示例8是优惠券秒杀简单代码的修改过程，可以加深印象，还可以巩固基础知识 本文仅限于非集群模式的场景 关于订单id 当商铺发优惠券后，大量用户就会去抢购。抢购后，就会生成订单，并插入到订单表。 当使用数据表自增主键做订单id时 id的规律性太明显 比如某用户今天下单后，其订单号
缓存是什么？缓存机制、Spring缓存管理、Redis数据一致性、缓存问题（缓存穿透、缓存雪崩、缓存击穿）及Redis与MySQL使用场景对比
最新发布
项目git同名HuYaochao，未入职
09-30 1381
缓存机制、Spring缓存管理、Redis数据一致性、缓存问题（缓存穿透、缓存雪崩、缓存击穿）及Redis与MySQL使用场景对比
Redis: 持久化之RDB和AOF
Wang的专栏
09-29 1076
Redis 有一个高质量的课题：数据安全性与数据可靠性Redis 是一个内存型数据库，数据大部分都是存在内存里面当信息在内存中流通时，Redis 节点突然就故障挂掉当重新启动的时候，内存中的数据肯定是全部丢失了如果在这种情况下，Redis 提供了对应的持久化方案，它有两种持久化方案RDB和AOF可以把内存中的数据保存到磁盘，避免数据的流失关于RDB，我们需要了解到什么是持久化什么是快照RDB的工作原理，包括它的优点和缺点关于AOF，需要知道为什么需要有AOF。
Redis-常见数据类型(修改ing)
qq_74812898的博客
09-29 1021
redis常用数据类型
解决高并发抢购中的库存超卖问题与Redis应用
"本文将探讨如何设计高并发的抢购功能，主要利用Redis缓存以及事务处理技术，解决库存超卖问题和高并发对数据库的压力。" 在开发高并发的抢购或秒杀功能时，系统面临的主要挑战是短时间内大量用户同时访问带来的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值