redis学习(012 实战:黑马点评:优惠券秒杀——秒杀下单)

最新推荐文章于 2025-04-21 19:26:09 发布
原创 最新推荐文章于 2025-04-21 19:26:09 发布 · 358 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #学习 #数据库 #java #spring #spring boot

黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目

总时长 42:48:00 共175P

此文章包含第50p-第p51的内容

文章目录

添加优惠券

在这里插入图片描述
优惠券表包含了秒杀券
在这里插入图片描述

秒杀表相当于一个拓展字段表（三大范式：不根据范式会有数据冗余，但是有一些冗余会对系统的性能得到提升）
在这里插入图片描述

上架优惠券（秒杀券）

在这里插入图片描述

这个对象类添加了秒杀券的信息 两种都可以添加
在这里插入图片描述

在这里插入图片描述

为了避免小数 这里使用8000和10000对应的是80.00元抵100.00元
在这里插入图片描述
在这里插入图片描述

注意结束时间，前端应该是会判断结束时间，已经结束的不会显示

在这里插入图片描述

实现优惠券秒杀下单

在这里插入图片描述
在这里插入图片描述

实现下单的流程

在这里插入图片描述
代码流程
在这里插入图片描述
在这里插入图片描述
使用MyBatisplus进行库存扣减
在这里插入图片描述

在这里插入图片描述
记得加事务
在这里插入图片描述
测试通过
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

黑马点评--优惠卷秒杀
weixin_53050118的博客
11-16 1188
在VoucherController中提供一个接口，可以添加秒杀优惠券：http://localhost:8081/voucher/seckill。通过加锁可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了。现在，用户请求会在这两个节点上负载均衡，再次测试下是否存在线程安全问题。需求：修改秒杀业务，要求同一个优惠券，一个用户只能下一单。2.乐观锁：不加锁，在更新时判读是否有其它线程在修改。CAS法（CompareAndSet）1.悲观锁：添加同步锁，让线程串行执行。
【黑马点评】优惠券秒杀（单体模式）
weixin_42904738的博客
08-27 1147
基于乐观锁解决库存超卖问题在更新数据时判断当前查到的库存值是否充足，如果库存不足就直接返回错误信息。判断条件从“当前库存值与之前查到的库存值是否一致”弱化为“当前查到的库存值是否充足”，依然可以解决库存超卖问题，并且可以降低异常率。基于悲观锁解决一人一单线程安全问题将从“判断是否下过单”开始的代码提取出来，作为子方法该子方法中包括了扣减库存和创建订单两个操作，为保证原子性，需要为子方法加上注解。
黑马点评day03优惠券秒杀（超卖问题）
weixin_54161951的博客
06-28 1156
具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后再根据优惠卷id和用户id查询是否已经下过这个订单，如果下过这个订单，则不再下单，否则进行下单。
黑马Redis视频教程实战篇（三）
qq_38196449的博客
05-28 1142
重入问题：重入问题是指获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。
黑马点评：优惠券秒杀
Htupc的博客
02-12 2139
黑马点评：优惠券秒杀，乐观锁悲观锁
【Redis】Redis实战：黑马点评之优惠券秒杀
qq_50675319的博客
09-19 1739
每个店铺都可以发布优惠券：当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：id的规律性太明显如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。受单表数据量的限制。
基于Java和Redis的实战项目：黑马点评改进设计源码
09-30
本实战项目——黑马点评改进设计源码，不仅是一个具体的项目实践，也是一个深入学习和应用Java与Redis技术的宝贵资源。该项目共有75个文件，涵盖Java源文件、配置文件等多种类型，全面展现了在实际开发中如何有效地...
Redis项目实战——黑马点评(优惠卷秒杀部分)
m0_60301012的博客
06-17 2239
redis实战-黑马点评的优惠券秒杀部分
【Redis】Redis实战：黑马点评之秒杀优化
qq_50675319的博客
09-21 1388
通过加锁可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了。1.我们将服务启动两份，端口分别为8081和8082：2.然后修改nginx的conf目录下的nginx.conf文件，配置反向代理和负载均衡：3.重新加载nginx，命令为4.经过测试，最终发现在集群模式下，有多少个服务，用户最多就能下多少单，也就是说在集群模式下，我们之前使用的悲观锁失效了为什么会出现上述现象呢？
07、Redis实战：优惠券秒杀、优化异步下单
u012011912的博客
08-22 1049
秒杀业务的优化思路是什么？
黑马点评：优惠券系列
weixin_49007640的博客
12-24 1165
黑马点评：优惠券系列
黑马点评3——优惠券秒杀—全局唯一ID、秒杀下单、超卖问题（乐观锁）、一人一单问题（并发安全）
shall_zhao的博客
08-31 3158
以前我们的优惠券下单业务是这样的：现在修改业务流程@Override// 1. 查询优惠券// 2. 判断秒杀是否开始// 尚未开始return Result.fail("秒杀尚未开始！");// 2/ 判断秒杀是否结束// 已经结束return Result.fail("秒杀已经结束！");// 4. 判断库存是否充足// 库存不足return Result.fail("库存不足！");// 5. 一人一单// 5.1 查询订单// 5.2 判断是否存在。
Redis实战—黑马点评项目—优惠券秒杀
LHB123456789L的博客
03-22 759
优惠券秒杀 笔记
【Redis | 黑马点评 + 思维导图】优惠卷秒杀
十八岁讨厌编程的博客
02-05 1386
本文涉及全局唯一ID、添加优惠卷业务、实现秒杀下单、库存超卖问题分析、实现秒杀的一人一单、集群环境下的并发问题等内容。
Redis【黑马点评】——2 秒杀
qq_45730261的博客
10-16 2277
秒杀是该项目中非常重要的一个模块，涵盖的知识点以及代码质量非常之高，里面有许多细节值得反复学习观看，能帮助我们获得非常有用的知识。这篇文章除了对该秒杀功能进行了总计，还包括许多细节的分析，如：如何加锁，为什么加这个锁，加在哪里，以及涉及了动态代理等知识，对这个模块有疑问的小伙伴可以来学习，大家一起进步学习。
黑马点评 秒杀优惠券单体下一人一单超卖问题
2301_77021913的博客
04-12 1345
步骤操作并发安全措施查询优惠券信息检查时间、库存无用户加锁锁防止同一用户重复下单创建订单（事务）检查用户订单、扣库存、插入订单数据库乐观锁、事务隔离操作无事务的风险有事务的保障检查用户订单可能通过检查，但下单时冲突可重复读确保一致性扣减库存超卖（库存扣减到负数）数据库乐观锁（stock > 0）阻止超卖创建订单订单丢失或重复唯一键约束+原子提交保证数据完整。
Redis实战篇《黑马点评》3 优惠券秒杀
wyznan的博客
02-18 1061
失败原因分析：由于我们部署了多个Tomcat，每个Tomcat都有一个属于自己的jvm，那么假设在服务器A的Tomcat内部，有两个线程，即线程1和线程2，这两个线程使用的是同一份代码，那么他们的锁对象是同一个，是可以实现互斥的。但是如果在Tomcat的内部，又有两个线程，但是他们的锁对象虽然写的和服务器A一样，但是锁对象却不是同一个，所以线程3和线程4可以实现互斥，但是却无法和线程1和线程2互斥。1.UUID利用JDK自带的工具类即可生成，生成的是16进制的字符串，无单调递增的特性。
黑马点评—优惠券秒杀相关
最新发布
yj000703的博客
04-21 1623
具体场景举例：线程1获取Redis分布式锁后执行业务逻辑，但是由于某种原因导致其业务阻塞直到Redis分布式锁被自动释放，此时线程2可以重新获取释放后的Redis分布式锁然后执行自己的任务，如果在线程2执行自己任务的过程中，线程1阻塞结束并且完成了自己的业务，按照之前的设计此时线程1会释放Redis分布式锁，但是由于当前的Redis分布式锁已经被线程2持有，所以线程1实际上释放的是线程2的Redis分布式锁，因此出现Redis分布式锁误删的情况。另外由于使用的是内存，如果服务宕机，用户的订单信息会丢失；
黑马点评-优惠券秒杀业务
cangshanjiang的博客
03-05 1552
每个店铺都可以发布同类优惠券，当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。随着我们商城规模越来越大，mysql的单表的容量不宜超过500W，数据量过大之后，我们要进行拆库拆表，但拆分表了之后，他们从逻辑上讲他们是同一张表，所以他们的id是不能一样的， 于是乎我们需要保证id的唯一性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值