黑马点评3——优惠券秒杀—全局唯一ID、秒杀下单、超卖问题（乐观锁）、一人一单问题（并发安全）

最新推荐文章于 2024-10-01 09:29:45 发布
最新推荐文章于 2024-10-01 09:29:45 发布
阅读量989 收藏 19
点赞数 10
分类专栏： 黑马点评redis 文章标签： java redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/shall_zhao/article/details/141754233
版权

文章目录

全局唯一ID

在这里插入图片描述
全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足一下特性：

在这里插入图片描述

基本格式如下：
在这里插入图片描述

UUID

返回的是16进制的

Redis自增

根据上面图示的格式，我们实现一个Redis自增的全局ID，注册成bean，交给Spring管理


@Component
public class RedisIdWorker {
    
    /**
     * 开始时间戳
     */
    private static final long BEGIN_TIMESTAMP = 1704067200L;
    /**
     * 序列号位数
     */
    private static final long 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 timestep = nowSecond - BEGIN_TIMESTAMP;
        // 2. 生成序列号
        // 2.1 获取当前日期，精确到天,好处1： 避免超过2^32, 2：方便统计
        String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        long count = stringRedisTemplate.opsForValue().increment("icr:"+keyPrefix + ":" + date);
        // 3. 拼接并返回
        return timestep << COUNT_BITS | count;
    }
}

单元测试：


    @Autowired
    private RedisIdWorker redisIdWorker;

    private ExecutorService es = Executors.newFixedThreadPool(500);

    @Test
    void testIdWorker() throws InterruptedException {
        // 使用 CountDownLatch 同步 300 个异步任务。
        // 确保所有任务完成后，计算并输出总的执行时间。
        // 通过这种方式，可以准确地测量所有任务的总执行时间，而不会因为异步执行导致时间计算不准确。
        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);  // 使用线程池 es 提交 300 个相同的任务。每个任务都会执行上面定义的操作。
        }
        latch.await();  // 调用 latch.await() 方法，使当前线程等待，直到计数器的值变为 0。这确保了所有 300 个任务都已完成。
        long end = System.currentTimeMillis();
        System.out.println("time = " + (end - begin));
    }

snowflake算法（雪花算法）

数据库自增

这里不是说使用数据库的自增字段，而是说单独使用一张表，专门用来做自增，订单表需要id，就从这张表里获取（redis自增的数据库版）

Redis自增id策略

  • 每天一个Key，方便统计订单量
  • ID构造是时间戳+计数器

实现优惠券秒杀下单

在这里插入图片描述
主要是针对特价券这种需要抢的，普通券就没必要了。

优惠券秒杀下单时要判断两点：

  • 秒杀是否开始或结束，如果尚未开始或已经结束则无法下单
  • 库存是否充足，不足无法下单
    在这里插入图片描述
@Override
    @Transactional
    public Result seckillVoucher(Long voucherId) {
        // 1. 查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2. 判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 2/ 判断秒杀是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 已经结束
            return 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);
    }

超卖问题

正常情况下没问题：
在这里插入图片描述
高并发环境下就有问题，不同线程的动作会交叉
在这里插入图片描述
如果同一时刻有很多的线程同时来查询，就出现了这个并发安全问题

多个线程在操作共享的资源，并且操作资源的代码有好几行，这几行代码执行的中间，多个线程互相穿插，就出现了安全问题。

在这里插入图片描述
悲观锁很简单暴力，直接加锁就行，我们演示乐观锁：
乐观锁的关键是判断之前查询得到的数据是否有被修改过， 常见的方式有两种：

乐观锁——版本号法

在这里插入图片描述
线程2在扣减库存的时候发现版本不一致就无法更新了
那现在我们想，我们即用库存，又用版本，比较版本的变化，是不是可以使用库存的变化代替呢？当然可以，于是乎，有了新方案：cas

乐观锁——CAS法

在这里插入图片描述
我们只需要把刚刚代码在扣减的时候加上关于库存的比较

@Override
    @Transactional
    public Result seckillVoucher(Long voucherId) {
        // 1. 查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2. 判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 2/ 判断秒杀是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 已经结束
            return Result.fail("秒杀已经结束！");
        }
        // 4. 判断库存是否充足
        if (voucher.getStock()<1) {
            // 库存不足
            return Result.fail("库存不足！");
        }
        // 5.扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock - 1")
                .eq("voucher_id", voucherId)
                .eq("stock",voucher.getStock())   // CAS锁
                .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);
    }

但我们使用jmeter进行测试，设置库存100件，并发线程200个，测试结果如下：
在这里插入图片描述
错误率高达68.5%
啊。不应该啊。
在看看数据库的库存：
在这里插入图片描述
还剩下79件？？？
订单也只有21个，没有超卖啊，安全问题确实解决了，那为什么出现了很多失败的情况呢？
还没卖完就结束了？怎么回事？

乐观锁的弊端

在这里插入图片描述
太小心了，他认为只要有人修改了就不执行，失败率大大提高
其实只要库存大于0， 就没问题。
这就是乐观锁的问题——成功率太低
其实解决方案很简单，就是把扣减库存的时候的

  // 5.扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock - 1")
                .eq("voucher_id", voucherId)
                .eq("stock",voucher.getStock())   // CAS锁
                .update();

这个严苛的判断条件改成只要库存大于0，就没必要大惊小怪的。

// 5.扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock - 1")
                .eq("voucher_id", voucherId)
                .gt("stock",0)   // 把判断条件改成库存大于0就可以避免乐观锁的弊端
                .update();

@Override
    @Transactional
    public Result seckillVoucher(Long voucherId) {
        // 1. 查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2. 判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 2/ 判断秒杀是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 已经结束
            return Result.fail("秒杀已经结束！");
        }
        // 4. 判断库存是否充足
        if (voucher.getStock()<1) {
            // 库存不足
            return Result.fail("库存不足！");
        }
        // 5.扣减库存
        boolean success = seckillVoucherService.update()
                .setSql("stock = stock - 1")
                .eq("voucher_id", voucherId)
                .gt("stock",0)   // 把判断条件改成库存大于0就可以避免乐观锁的弊端
                .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);
    }

100的库存，200的线程并发访问，jmeter测试结果：
在这里插入图片描述
数据库也减少到0了
在这里插入图片描述
当然这个解决方案不是所有情况都行的，还有其他的解决方案
比如：如果有的问题中没有库存怎么办？
采用分批加锁的方案，或者是分段锁的方案，也就是说把数据库中的资源分成几份，比如说把数据分成十份，那用户在抢的时候可以去10张表里面分别去抢，这样一来成功率就提高了10倍。这种思想在ConcurrentHashMap中有应用。

总结

在这里插入图片描述

一人一单

以前我们的优惠券下单业务是这样的：
在这里插入图片描述
现在修改业务流程
在这里插入图片描述
修改我们的业务代码如下：


    @Override
    @Transactional
    public Result seckillVoucher(Long voucherId) {
        // 1. 查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2. 判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 2/ 判断秒杀是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 已经结束
            return Result.fail("秒杀已经结束！");
        }
        // 4. 判断库存是否充足
        if (voucher.getStock()<1) {
            // 库存不足
            return Result.fail("库存不足！");
        }

        // 5. 一人一单
        Long userId = UserHolder.getUser().getId();
        // 5.1 查询订单
        Integer 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")
                .eq("voucher_id", voucherId)
                .gt("stock",0)   // 把判断条件改成库存大于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);
        // 8. 返回订单id
        return Result.ok(orderId);
    }

100的库存，200的线程并发访问，但是只配置一个用户的请求头，jmeter测试
理论上应该只能下一单才对，库存应该还剩下99个
看看数据库库存
在这里插入图片描述
订单表里面也有10个订单：
在这里插入图片描述
什么情况？里面的user_id和voucher_id竟然也是一样的！
说明我们做了一人一单的业务逻辑判断，但是并没有解决问题。
现在的问题就是因为先查询，在判断，在扣减，就是因为多个线程并发访问，多个线程一起查询count都是0，都说我可以扣减，那就出错了，那怎么解决呢？——加锁呀！
先暴力加个悲观锁，把查询订单和扣减库存的方法抽取出来：
Transactional注解也要换到扣减库存的方法上。

@Override
    public Result seckillVoucher(Long voucherId) {
        // 1. 查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2. 判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 2/ 判断秒杀是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 已经结束
            return Result.fail("秒杀已经结束！");
        }
        // 4. 判断库存是否充足
        if (voucher.getStock()<1) {
            // 库存不足
            return Result.fail("库存不足！");
        }

        return createVoucherOrder(voucherId);
    }

    @Transactional
    public synchronized Result createVoucherOrder(Long voucherId){
        // 5. 一人一单
        Long userId = UserHolder.getUser().getId();
        // 5.1 查询订单
        Integer 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")
                .eq("voucher_id", voucherId)
                .gt("stock",0)   // 把判断条件改成库存大于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);
        // 8. 返回订单id
        return Result.ok(orderId);
    }

锁加在方法上肯定可以解决，但是不建议，因为synchronized加在方法上，就变成了锁整个方法，锁的对象是this，也就意味着不管任何一个用户来了，都要加这个锁，而且大家是同一把锁，整个方法就串行执行了。我们想要的是只有同一个用户来了在加锁，不同用户来了就不用管。各做各就行，应该对用户id加锁。缩小加锁的范围。
注意两点：

  1. 释放锁的时机：我们的锁也不能加载createVoucherOrder方法里面，因为锁要是加载createVoucherOrder方法里面，会出现spring的事务还没提交就释放锁的问题。
  2. 事务失效问题
    我们在createVoucherOrder函数加了事务，没有给seckillVoucher函数加事务，而seckillVoucher函数调用的时候使用this调用的，事务失效，具体解释看代码里
@Override
    public Result seckillVoucher(Long voucherId) {
        // 1. 查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2. 判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 2/ 判断秒杀是否结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 已经结束
            return Result.fail("秒杀已经结束！");
        }
        // 4. 判断库存是否充足
        if (voucher.getStock()<1) {
            // 库存不足
            return Result.fail("库存不足！");
        }

        Long userId = UserHolder.getUser().getId();
        /**
         *          每一个请求过来，这个id对象都是一个全新的id对象，因为要是对userId加锁的话，对象变了锁就变了，那不行
         *          我们希望id的值一样，所以用了toString(),但是toString()依旧不能保证是对对象的值加锁的
         *          toString底层是new 一个String数组，还是new了一个新对象，同一个用户id在不同的请求中过来，每次都new一个，还是不能把锁加载同一个用户上
         *          于是用intern() ,intern()方法可以去字符串常量池中找字符串值一样的引用返回
         *          这样一来，如果你的userId是5，不管你new了多少个字符串，只要值是一样的，返回的结果也一样。这样就可以锁住同一个用户
         *          不同的用户不会被锁住
         */

        synchronized (userId.toString().intern()) {
            // 获取代理对象（事务）
            IVoucherOrderService proxy = (IVoucherOrderService)AopContext.currentProxy();  // 拿到当前对象的代理对象，其实就是IVoucherOrderService这个接口的代理对象，返回的是Object，做个强转
            return proxy.createVoucherOrder(voucherId);  // 如果报错了是因为我们的接口中没有这个方法，那我们就在接口中创建一下这个方法就行
        }
    }

    /**
     * 事务加在这，就失效了，为什么呢？
     * 加载这是对createVoucherOrder函数加了事务，没有给seckillVoucher函数加事务，而seckillVoucher函数调用的时候
     * createVoucherOrder(voucherId);
     * 这样使用this调用的，这个this拿到的是当前的VoucherOrderServiceImpl对象
     * 而不是VoucherOrderServiceImpl的代理对象
     * 而事务要想生效，是spring对当前这个类做了动态代理，拿到代理对象做的事务处理
     * 而我们当前的this是非代理对象，这就是事务失效的几种可能性之一
     * 解决方法之一：
     * AopContext.currentProxy()拿到代理对象来调用createVoucherOrder
     *
     * 当然这样解决还得做两件事：
     * 1. 引入aspectj的依赖
     *    <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjweaver</artifactId>
            <version>1.9.7</version>
        </dependency>
     * 2. 启动类添加注解@EnableAspectJAutoProxy(exposeProxy = true)暴露代理对象
     */
    @Transactional
    public Result createVoucherOrder(Long voucherId){
        // 5. 一人一单
        Long userId = UserHolder.getUser().getId();
        // 5.1 查询订单
        Integer 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")
                .eq("voucher_id", voucherId)
                .gt("stock",0)   // 把判断条件改成库存大于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);
        // 8. 返回订单id
        return Result.ok(orderId);

    }

100的库存，200的线程并发访问，但是只配置一个用户的请求头，jmeter测试
理论上应该只能下一单才对，库存应该还剩下99个
看看数据库库存对的。YES！！！

一人一单的并发安全问题

上面的解决方案在单机模式下不会有问题，但是在集群模式下就有问题了，什么问题呢？我们来测试
在这里插入图片描述
我们用postman使用同一个用户发送两个请求，在锁后打上断点，发现两个集群下两个服务都进入断点了，这一个锁在集群模式下没有锁住，放开后也发现数据库的数据被同一个用户扣减了两个。为什么呢？
来捋一下：
之前是单体项目，正常情况下：
在这里插入图片描述
多线程并发下，要是没有加锁，会出现并发执行：
在这里插入图片描述
这就出现了线程安全问题。于是我们加了锁
在这里插入图片描述
在集群情况下就出问题了：
现在我们是多台JVM下，锁的原理是，在JVM内部维护一个锁监视器对象，这个监视器对象用的userId，userId在常量池中。在这个JVM内部维护了一个常量池，当userId相同的情况下，永远是同一个锁，也就是锁的监视器就能记录不同线程的情况。
但是当集群的时候，那就各自有各自的JVM，那各自的JVM都有各自的堆、栈、方法区之类的。JVM2也会有自己的常量池，JVM2 的锁监视器只能在当前的JVM内部见识线程，实现互斥。
在这里插入图片描述
这就有一次出现了并发安全问题，每一个JVM都有自己的锁，就导致并行运行下，就出现问题了，那就得让多个JVM只能使用同一把锁，但这样的锁不是JDK提供的，于是乎跨JVM，或者跨进程的锁就出现了——分布式锁

shall_zhao
关注
专栏目录
黑马点评-优惠券秒杀
weixin_57393590的博客
10-16 930
redis分布式锁
【Redis】Redis实战：黑马点评之优惠券秒杀
qq_50675319的博客
09-19 1357
每个店铺都可以发布优惠券：当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：id的规律性太明显如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。受单表数据量的限制。
黑马点评day03优惠券秒杀（超卖问题）
weixin_54161951的博客
06-28 777
具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后再根据优惠卷id和用户id查询是否已经下过这个订单，如果下过这个订单，则不再下单，否则进行下单。
《黑马点评》优惠券秒杀的一点笔记
易琳的博客
06-08 826
关于代理对象事务的问题：通常情况下，当一个使用了@Transactional注解的方法被调用时，Spring会从上下文中获取一个代理对象来管理事务。但是如果加@Transactional方法是被同一个类中的另一个方法调用时，Spring不会使用代理对象，而是直接调用该方法，导致事务注解失效。因此最终方案是把synchronized加在createVoucherOrder的方法外部，锁住的是用户id。首先不建议把锁加在方法上，因为任何一个用户来了都要加这把锁，而且是同一把锁，方法之间变成串行执行，性能很差。
黑马点评Redis实战(优惠卷秒杀)
qq_47155894的博客
05-12 1030
本文是上一篇文章的后续，上一篇文章链接。
黑马Redis——黑马点评项目记录
Ydin00的博客
03-24 3289
这已经是我第三次看这个项目了，第一次看这个是七八个月以前，第二次看是三个月以前，现在为了简历内容，我打算第三次再回顾一遍这个项目，不得不说这个项目对我学习redis真的是很有帮助。
黑马点评项目笔记
studyForMokey的博客
02-25 1638
点评项目
《黑马点评》项目复盘--功能实现(2)
Wifi_baba的博客
05-14 690
基于Redis的分布式锁实现思路：①通过setnx ex实现互斥，并设置过期时间（保证在故障时锁依然可以释放，避免死锁，提升安全性），保存线程标识。②释放锁时需要判断是否与当前id一致，再进行释放锁操作。lua脚本保证原子性。消息队列，字面意思就是存放消息的队列。消息队列：存储和管理消息，也就是消息代理。生产者：发送消息到消息队列消费者：从消息队列中获取消息并处理消息特点。
PHP商品秒杀问题解决方案实例详解【mysql与redis】
10-16
乐观锁虽然可以解决并发问题，但是它可能会导致用户体验的问题。因为实际的用户抢购顺序可能没有被完全反映出来，因此可能造成抢购时间早的用户抢购失败。 #### 3. 基于Redis的解决方案 Redis在处理高并发数据时...
黑马Redis实战项目——黑马点评笔记04 | 优惠券秒杀
2301_77450803的博客
04-25 1089
使用postman添加秒杀券//秒杀券信息 {
黑马点评详细总结（问题 + 踩坑点 + 解决思路）
06-15
在"黑马点评详细总结"这个项目中，我们关注的是一个类似大众点评的平台，它大量使用了Redis这一内存数据存储系统。项目的主要功能包括短信登录和注册，以及相关的用户验证流程。以下是对这些关键知识点的详细说明： ...
Redis学习笔记 --------黑马点评项目
m0_59640673的博客
08-19 303
缓存，数据交换的缓冲区优势：减低后端负载，提高读写效率劣势：数据一致性，代码维护成本，运维成本浏览器发送的请求的数据，在redis和数据库中都未命中，即不存在这个数据，这些数据都会一直访问数据库（可能会存在恶意攻击的情况）（满足其一）同一时间大量缓存的key失效（批量添加数据…）Redis宕机一个高访问并且==缓存重建业务比较复杂（时间相对较久）==的key失效了结果：无数的请求会在重建缓存时，给数据库带来巨大的压力是一种在分布式系统下用来生成全局唯一ID的工具。
黑马点评项目遇到的部分问题
Suburbia的博客
04-21 1662
此时，当这个有注解的方法被调用的时候，实际上是由代理类来调用的，代理类在调用之前就会启动transaction。然而，如果这个有注解的方法是被同一个类中的其他方法调用的，那么该方法的调用并没有通过代理类，而是直接通过原来的那个bean，所以就不会启动transaction，我们看到的现象就是@Transactional注解无效。在同一个类中，一个方法调用另外一个有注解（比如@Async，@Transational）的方法，注解是不会生效的，所以我们需要创建一个代理对象，使用代理对象来调用方法。
黑马Redis视频教程实战篇（三）
qq_38196449的博客
05-28 966
重入问题：重入问题是指获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。
java将word转pdf
紫月7575的博客
09-30 527
java将word转pdf
spring-boot 整合 mybatis
m0_72168501的博客
09-29 548
spring boot 整合 mybatis
Java内存布局
最新发布
阿呆的专栏
10-01 802
64位 JVM 不启用指针压缩时：Object Header 大小是16字节。64位 JVM 启用指针压缩时（默认）：Object Header 大小是12字节。32位 JVM：Object Header 大小是8字节。JVM在默认情况下启用指针压缩，但如果堆内存超过32GB，就会禁用指针压缩。32GB是压缩指针的最大寻址范围。超过32GB的堆内存中，压缩指针带来的性能提升并不显著，而且需要解压指针反而可能增加开销。
C#基础：掌握控制流语句，构建灵活的程序逻辑
学习和分享
09-28 340
在C#中，控制流语句是用来控制程序执行流程的重要部分。它们允许你根据条件执行不同的代码块，或者重复执行某些代码块直到满足特定条件。
黑马rabbitMQ优惠卷秒杀
03-23
黑马rabbitMQ优惠卷秒杀是指利用RabbitMQ消息队列来实现优惠卷的秒杀活动。RabbitMQ是一个开源的消息队列中间件，它可以实现高效的消息传递和异步通信。在秒杀活动中，由于瞬间会有大量用户同时请求抢购，传统的同步处理方式无法满足高并发的需求，而使用RabbitMQ可以将请求异步化，提高系统的并发处理能力。 具体实现过程如下： 1. 创建一个消息队列：首先需要创建一个RabbitMQ消息队列，用于存储用户的秒杀请求。 2. 生成优惠卷：在秒杀活动开始前，需要提前生成一定数量的优惠卷，并将其存储在数据库中。 3. 用户抢购请求：用户在秒杀活动开始时，发送抢购请求到消息队列中。 4. 消费者处理请求：创建多个消费者来监听消息队列中的请求，并进行处理。当有新的请求进入队列时，消费者会从队列中获取请求，并进行相应的处理逻辑。 5. 校验优惠卷：消费者在处理请求时，会先校验用户是否有资格参与秒杀活动，并检查优惠卷的库存情况。 6. 分发优惠卷：如果用户符合条件并且优惠卷有库存，消费者会将优惠卷分发给用户，并更新数据库中的库存信息。 7. 返回结果：消费者处理完请求后，将处理结果返回给用户，告知用户是否成功抢购。 通过使用RabbitMQ消息队列，可以有效地解决高并发场景下的请求处理问题，提高系统的性能和稳定性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值