【黑马点评】优惠券秒杀

仰望-星空~~

已于 2023-08-26 10:11:41 修改

阅读量95

点赞数

文章标签： redis java

于 2023-08-26 10:09:24 首次发布

本文链接：https://blog.csdn.net/weixin_65935065/article/details/132508106

版权

【黑马点评】优惠券秒杀

一、全局唯一ID

1、问题简介

每个店铺都可以发布优惠券：
在这里插入图片描述

当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，

表结构：
在这里插入图片描述

这里订单id并未设置自增，而订单表如果使用数据库自增ID就存在一些问题：

id的规律性太明显：容易向用户泄露一些信息
受单表数据量的限制

业务场景分析：

场景分析一：如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。

场景分析二：随着我们商城规模越来越大，mysql的单表的容量不宜超过500W，数据量过大之后，我们要进行拆库拆表，但拆分表了之后，他们从逻辑上讲他们是同一张表，所以他们的id是不能一样的，于是乎我们需要保证id的唯一性。

以上问题可以通过全局ID生成器来解决

2、全局ID生成器

全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足下列特性：

在这里插入图片描述

为了增加ID的安全性，我们可以不直接使用Redis自增的数值，而是拼接一些其它信息：
在这里插入图片描述

时间戳：31bit，以秒为单位，可以使用69年

序列号：32bit，秒内的计数器，支持每秒产生2^32个不同ID

3、Redis实现全局唯一Id

新建一个类

@Component
public class RedisIdWorker {
    /**
     * 初始时间戳
     * 运行main方法所得
     */
    private static final long BEGIN_TIMESTAMP=1640995200L;
    /**
     * 序列号的位数
     */
    private static final int COUNT_BITS=32;

    private StringRedisTemplate stringRedisTemplate;

    public RedisIdWorker(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    public long nextId(String keyPrefix){
        //1、生成时间戳
        LocalDateTime now = LocalDateTime.now();
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        long timestamp=nowSecond-BEGIN_TIMESTAMP;

        //2、生成序列号
        //2.1、获取当天日期，精确到天
        now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        //2.2、自增长
        Long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + "20220910");
        //3、拼接并返回
        return timestamp<<COUNT_BITS|count;
    }
    //生成一个初始值
    public static void main(String[] args) {
        LocalDateTime time = LocalDateTime.of(2022, 1, 1, 0, 0, 0);
        long second = time.toEpochSecond(ZoneOffset.UTC);
        System.out.println("second="+second);
    }
}

测试：

//注入类
@Resource
    private RedisIdWorker redisIdWorker;
	//创建线程池
    private ExecutorService es= Executors.newFixedThreadPool(500);
    @Test
    void testIdWorker() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(300);

        Runnable task = () -> {
            for (int i = 0; i < 100; i++) {
                long id = redisIdWorker.nextId("order");
                System.out.println("id = " + id);
            }
            latch.countDown();
        };
        long begin = System.currentTimeMillis();
        for (int i = 0; i < 300; i++) {
            es.submit(task);
        }
        latch.await();
        long end = System.currentTimeMillis();
        System.out.println("time = " + (end - begin));
    }

结果

在这里插入图片描述

二、实现优惠券添加、秒杀下单

1、添加优惠券

每个店铺都可以发布优惠券，分为平价券和特价券。平价券可以任意购买，而特价券需要秒杀抢购：

在这里插入图片描述

tb_voucher：平价优惠券的基本信息，优惠金额、使用规则等

在这里插入图片描述

tb_seckill_voucher：优惠券的库存、开始抢购时间，结束抢购时间。特价优惠券才需要填写这些信息

在这里插入图片描述

平价卷由于优惠力度并不是很大，所以是可以任意领取

而代金券由于优惠力度大，所以像第二种卷，就得限制数量，从表结构上也能看出，特价卷除了具有优惠卷的基本信息以外，还具有库存，抢购时间，结束时间等等字段

1）新增普通卷代码：VoucherController

@PostMapping
public Result addVoucher(@RequestBody Voucher voucher) {
    voucherService.save(voucher);
    return Result.ok(voucher.getId());
}

2）新增秒杀券代码：VoucherController

@PostMapping("seckill")
public Result addSeckillVoucher(@RequestBody Voucher voucher) {
    voucherService.addSeckillVoucher(voucher);
    return Result.ok(voucher.getId());
}

VoucherServiceImpl

@Override
@Transactional
public void addSeckillVoucher(Voucher voucher) {
    // 保存优惠券
    save(voucher);
    // 保存秒杀信息
    SeckillVoucher seckillVoucher = new SeckillVoucher();
    seckillVoucher.setVoucherId(voucher.getId());
    seckillVoucher.setStock(voucher.getStock());
    seckillVoucher.setBeginTime(voucher.getBeginTime());
    seckillVoucher.setEndTime(voucher.getEndTime());
    seckillVoucherService.save(seckillVoucher);
    // 保存秒杀库存到Redis中
    stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());
}

3）测试新增秒杀券

post请求  http://localhost:8080/api/voucher/seckill

添加优惠券信息

注意：开始时间需要设置为当前时间或往后，和结束时间，不然优惠券就是过期的，不会在页面中显示

{
    "shopId":1,
    "title":"100元代金券",
    "subTitle":"周一至周日均可使用",
    "rules":"全场通用\n无需预约\n可无限叠加\n不兑现、不找零\n仅限堂食",
    "payValue":8000,
    "actualValue":10000,
    "type":1,
    "stock":100,
    "biginTime":"2023-01-26T10:08:12",
    "endTime":"2023-05-26T23:09:04"
}

结果：

两张表的id是一样的

tb_voucher表

在这里插入图片描述

tb_seckill_voucher表

在这里插入图片描述

这里的8000和10000其实是80和100，前面是有两个小数点的

网站页面显示：可以看到秒杀券添加成功

点击后需要先进行登录

在这里插入图片描述

2、实现优惠券秒杀下单

1️⃣实现思路

下单核心思路：当我们点击抢购时，会触发右侧的请求，我们只需要编写对应的controller即可

对应的controller类是VoucherOrderController

在这里插入图片描述

下单时需要判断两点：

秒杀是否开始或结束，如果尚未开始或已经结束则无法下单
库存是否充足，不足则无法下单

下单核心逻辑分析：

当用户开始进行下单，我们应当去查询优惠卷信息，查询到优惠卷信息，判断是否满足秒杀条件

比如时间是否充足，如果时间充足，则进一步判断库存是否足够，如果两者都满足，则扣减库存，创建订单，然后返回订单id，如果有一个条件不满足则直接结束。

在这里插入图片描述

2️⃣实现流程

1、查询优惠券

2、判断秒杀是否开始

3、判断是否结束

4、判断库存是否充足

5、扣减库存

6、创建订单——只需要用户id、订单id、代金券id

7、返回订单id

3️⃣实现步骤

1）创建seckillVoucher方法

@RestController
@RequestMapping("/voucher-order")
public class VoucherOrderController {
    @Resource
    private IVoucherOrderService voucherOrderService;

    @PostMapping("seckill/{id}")
    public Result seckillVoucher(@PathVariable("id") Long voucherId) {

        return voucherOrderService.seckillVoucher(voucherId);
    }
}

2）创建该方法的接口

public interface IVoucherOrderService extends IService<VoucherOrder> {
    Result seckillVoucher(Long voucherId);
}

3）实现该方法

@Service
public class VoucherOrderServiceImpl extends ServiceImpl<VoucherOrderMapper, VoucherOrder> implements IVoucherOrderService {

    @Resource
    private ISeckillVoucherService seckillVoucherService;

    @Resource
    private RedisIdWorker redisIdWorker;
    @Override
    //添加事务回滚
    @Transactional
    public Result seckillVoucher(Long voucherId) {
        //1、查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        //2、判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())){
            //尚未开始
            Result.fail("秒杀尚未开始！！！");
        }
        //3、判断是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())){
            //尚未开始
            Result.fail("秒杀已经结束！！！");
        }
        //4、判断库存是否充足
        if (voucher.getStock()<1) {
            //库存不足
            return Result.fail("库存不足！！！");
        }
        //5、扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock=stock-1")
                .eq("voucher_id", voucherId).update();
        if (!success) {
            //扣减失败
            return Result.fail("库存不足！！！");
        }
        //6、创建订单——需要
        VoucherOrder voucherOrder=new VoucherOrder();
        //6.1、订单id
        long orderId = redisIdWorker.nextId("order");
        voucherOrder.setId(orderId);
        //6.2、用户id
        Long userId = UserHolder.getUser().getId();
        voucherOrder.setUserId(userId);
        //6.3、代金券id
        voucherOrder.setVoucherId(voucherId);
        save(voucherOrder);

        //7、返回订单id
        return Result.ok(orderId);
    }
}

4）效果

在这里插入图片描述

可以看到订单抢购成功，并且输出了订单号，后端控制台也输出了相关订单信息

在这里插入图片描述

订单id号是相同的，只不过我点击了两次，出现了两个订单号，我把其中一个订单信息删除了

三、超卖问题

上面的优惠券秒杀券，是一个人点击，但实际场景中一秒钟可能存在上千个人同时点击

那如何保证我们的请求接口还能正常工作

这里我们有一百张券，有两百个用户同时开抢，我们的预期是只卖出100张券，生成一百张订单

1、问题导入

我们用Jmeter测试一下

请求信息：

post请求 http://localhost:8081/voucher-order/seckill/10

在这里插入图片描述

这里需要注意：

因为抢券前我们是需要先登陆的，而这里模拟并发，我们没有登录，所以必须修改请求

请求必须要加入请求头信息，不然会报错401

添加HTTP信息头管理器，设置添加token，这个token就是用户登录的信息

在这里插入图片描述

token的信息也可以在缓存中找到

添加token

token  authorization:bce51e2d14ab4ac7b80e85cb2241e366

在这里插入图片描述

我这里的200个请求都运行成功了

然而在秒杀表tb_seckill_voucher中库存剩-1

订单表中插入了109条记录

这就出现了问题：

库存原本只有100，抢购后却变成了-9：出现了超卖

视频中的结果是订单表109条记录，超卖九张，虽然不一样但是没有关系

如果和视频中的不一致，没关系

这种情况很可能是因为多个用户同时提交订单导致的并发竞争问题。在系统处理用户秒杀请求时，未对更新库存进行加锁或者锁的持有时间过短，导致多个线程同时执行库存减一操作，从而造成了实际下单数少于用户请求数的情况。

2、问题分析

原有代码逻辑

if (voucher.getStock() < 1) {
        // 库存不足
        return Result.fail("库存不足！");
    }
    //5，扣减库存
    boolean success = seckillVoucherService.update()
            .setSql("stock= stock -1")
            .eq("voucher_id", voucherId).update();
    if (!success) {
        //扣减库存
        return Result.fail("库存不足！");
    }

假设线程1过来查询库存，判断出来库存大于1，正准备去扣减库存，但是还没有来得及去扣减，此时线程2过来，线程2也去查询库存，发现这个数量一定也大于1，那么这两个线程都会去扣减库存，最终多个线程相当于一起去扣减库存，此时就会出现库存的超卖问题。

在这里插入图片描述

3、解决方案

超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁：而对于加锁，我们通常有两种解决方案：

在这里插入图片描述

悲观锁：

悲观锁可以实现对于数据的串行化执行，比如syn，和lock都是悲观锁的代表，同时，悲观锁中又可以再细分为公平锁，非公平锁，可重入锁，等等

乐观锁：

乐观锁：会有一个版本号，每次操作数据会对版本号+1，再提交回数据时，会去校验是否比之前的版本大1 ，如果大1 ，则进行操作成功，这套机制的核心逻辑在于，如果在操作过程中，版本号只比原来大1 ，那么就意味着操作过程中没有人对他进行过修改，他的操作就是安全的，如果不大1，则数据被修改过，当然乐观锁还有一些变种的处理方式比如cas

乐观锁的典型代表：就是cas，利用cas进行无锁化机制加锁，var5 是操作前读取的内存值，while中的var1+var2 是预估值，如果预估值 == 内存值，则代表中间没有被人修改过，此时就将新值去替换内存值

4、使用乐观锁解决问题

版本号法：

在这里插入图片描述

库存CAS法：

在这里插入图片描述

他的操作逻辑是在操作时，对版本号进行+1 操作，然后要求version 如果是1 的情况下，才能操作，那么第一个线程在操作后，数据库中的version变成了2，但是他自己满足version=1 ，所以没有问题，此时线程2执行，线程2 最后也需要加上条件version =1 ，但是现在由于线程1已经操作过了，所以线程2，操作时就不满足version=1 的条件了，所以线程2无法执行成功

在这里插入图片描述

VoucherOrderServiceImpl实现类中

在这里插入图片描述

修改部分：

//5、扣减库存
//boolean success = seckillVoucherService.update()
//        .setSql("stock= stock -1")
//        .eq("voucher_id", voucherId).update();
boolean success = seckillVoucherService.update()
.setSql("stock=stock-1") //set stock=stock-1
//where id=1? and stock>0
.eq("voucher_id", voucherId).gt("stock",0)
.update();

结果：

100张票全部卖完，生成100张订单，并且库存为0，并没有出现超买的情况

四、一人一单

1、问题分析

需求：修改秒杀业务，要求同一个优惠券，一个用户只能下一单

优惠卷是为了引流，但是目前的情况是，一个人可以无限制的抢这个优惠卷，所以我们应当增加一层逻辑，让一个用户只能下一个单，而不是让一个用户下多个单

具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后再根据优惠卷id和用户id查询是否已经下过这个订单，如果下过这个订单，则不再下单，否则进行下单

在这里插入图片描述

2、第一次修改

初始代码修改：

VoucherOrderServiceImpl实现类

//6、一人一单
        Long userId = UserHolder.getUser().getId();
        //6.1、查询订单——不需要查具体的id值，只需要查数量就行
        Integer count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
        //6.2、判断是否存在
        if (count>0) {
            //表示用户已下过一单
            return Result.fail("该用户已经购买过一次！");
        }
        //7、创建订单——需要
        VoucherOrder voucherOrder=new VoucherOrder();
        //7.1、订单id
        long orderId = redisIdWorker.nextId("order");
        voucherOrder.setId(orderId);
        //7.2、用户id
        //Long userId = UserHolder.getUser().getId();这段代码转移到了顶部
        voucherOrder.setUserId(userId);
        //7.3、代金券id
        voucherOrder.setVoucherId(voucherId);
        save(voucherOrder);

        //7、返回订单id
        return Result.ok(orderId);

结果预期：

同样是200个请求，结果应该是订单数只有一个，库存还剩99

运行后却发现还是出现了一人下多单的情况

这还是因为并发出现的线程穿插的情况

3、悲观锁解决并发

**存在问题：**现在的问题还是和之前一样，并发过来，查询数据库，都不存在订单，所以我们还是需要加锁，但是乐观锁比较适合更新数据，而现在是插入数据，所以我们需要使用悲观锁操作

首先我们的初始方案是封装了一个createVoucherOrder方法，同时为了确保他线程安全，在方法上添加了一把synchronized 锁

注意：

如果把锁加在方法上，那么锁的范围就是整个方法，而且不管是任何一个用户都要加锁，而且都是同一把锁

所以我们锁的对象应该是用户id，减小资源的范围

同一个用户加一把锁，不同用户加不同锁

userId.toString().intern()  //确保当用户id的值一样时锁就是一样的

创建了一个createVoucherOrder方法，来封装这段逻辑

@Override
    @Transactional
    public Result createVoucherOrder(Long voucherId) {
        //5、一人一单
        Long userId = UserHolder.getUser().getId();
        //5.1、查询订单——不需要查具体的id值，只需要查数量就行
        int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
        //5.2、判断是否存在
        if (count > 0) {
            //表示用户已下过一单
            return Result.fail("该用户已经购买过一次！");
        }
        //6、扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock=stock-1") //set stock=stock-1
                //where id=1? and stock>0
                .eq("voucher_id", voucherId).gt("stock",0)
                .update();
        if (!success) {
            //扣减失败
            return Result.fail("库存不足！！！");
        }

        //7、创建订单——需要
        VoucherOrder voucherOrder = new VoucherOrder();
        //7.1、订单id
        long orderId = redisIdWorker.nextId("order");
        voucherOrder.setId(orderId);
        //7.2、用户id

        voucherOrder.setUserId(userId);
        //7.3、代金券id
        voucherOrder.setVoucherId(voucherId);
        save(voucherOrder);

        //7、返回订单id
        return Result.ok(orderId);
    }

给seckillVoucher方法的最后一段添加

//足够，创建订单
Long userId = UserHolder.getUser().getId();
synchronized (userId.toString().intern()) {
    //获取代理对象（事务）
    IVoucherOrderService proxy= (IVoucherOrderService) AopContext.currentProxy();
    return proxy.createVoucherOrder(voucherId);
}//先提交事务再释放锁

在IVoucherOrderService接口中创建createVoucherOrder方法

Result createVoucherOrder(Long voucherId);

pom.xml文件中加依赖

<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
</dependency>

启动类

//暴露代理对象
@EnableAspectJAutoProxy(exposeProxy = true)

运行结果：

预期是一人一单，订单只生成一个，而库存剩99

在这里插入图片描述

4、集群下的线程并发安全问题

通过加锁可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了。

1）模拟集群模式下的并发

1、我们将服务启动两份，端口分别为8081和8082：

在这里插入图片描述

2、然后修改nginx的conf目录下的nginx.conf文件，配置反向代理和负载均衡

在这里插入图片描述

修改/api——将api的路经代理到backand

3、重新加载配置文件

nginx.exe -s reload

现在用户请求会在这两个节点上负载均衡，再次测试是否存在线程安全问腿

4、测试

我们访问8080端口，nginx会代理到8081和8082这两个端口

http://localhost:8080/api/voucher/list/1

发送两次请求，数据会平均分配到两个端口中

两个端口运行的控制台中都输出了数据信息，测试成功

5、悲观锁测试

我们用同一个用户发起两次请求

post请求  http://localhost:8080/api/voucher-order/seckill/10

在这里插入图片描述

使用两个不同端口运行，debug一下

在这里插入图片描述

发现问题：两个请求都得到了用户id,说明我们的锁失效了

但是我这里查询数据库表却发现库存并没有减少两个，而是一个,而且订单也只生成一个

视频中减少了两个，原因不知

2）锁失效的原因

由于现在我们部署了多个tomcat，每个tomcat都有一个属于自己的jvm，那么假设在服务器A的tomcat内部，有两个线程，这两个线程由于使用的是同一份代码，那么他们的锁对象是同一个，是可以实现互斥的，但是如果现在是服务器B的tomcat内部，又有两个线程，但是他们的锁对象写的虽然和服务器A一样，但是锁对象却不是同一个，所以线程3和线程4可以实现互斥，但是却无法和线程1和线程2实现互斥，这就是集群环境下，syn锁失效的原因，在这种情况下，我们就需要使用分布式锁来解决这个问题。

在这里插入图片描述

仰望-星空~~

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【黑马点评】优惠券秒杀

每个店铺都可以发布优惠券：当用户抢购时，就会生成订单并保存到这张表中，表结构：业务场景分析：场景分析一：如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。场景分析二：随着我们商城规模越来越大，mysql的单表的容量不宜超过500W，数据量过大之后，我们要进行拆库拆表，但拆分表了之后，他们从逻辑上讲他们是同一张表，所以他们的id是不能一样的，于是乎我们需要保证id的唯一性。以上问题可以通过全局ID生成器来解决。
复制链接

扫一扫