springboot整合redis 分布式秒杀优化

CSDN话题挑战赛第2期
参赛话题:

文章目录

      • ⚡1.场景
        • 1.1 集群环境下的并发问题
      • 2. 分布式锁
        • 2.1 基本原理和实现方式对比
        • 2.2 、Redis 分布式锁的实现核心思路
        • 2.3 实现分布式锁版本一
        • 2.4 Redis 分布式锁误删情况说明
        • 4.5 解决 Redis 分布式锁误删问题
        • 4.6 分布式锁的原子性问题
      • ❄️3. 分布式锁 - redission
        • 3.1 分布式锁 - redission 功能介绍
        • 3.2 分布式锁 - Redission 快速入门
      • 4、秒杀优化
        • 4.1 秒杀优化 - 异步秒杀思路
        • 4.2 秒杀优化 - Redis 完成秒杀资格判断
      • 小结

⚡1.场景

上期我们演示了在单人单机场景下的乐观锁秒杀业务,但是在集群模式下就不行了,在集群模式下会造成诸多并发问题,下面来看具体场景:

1.1 集群环境下的并发问题

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

springboot整合redis 分布式秒杀优化_第1张图片

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

springboot整合redis 分布式秒杀优化_第2张图片
有关锁失效原因分析

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

springboot整合redis 分布式秒杀优化_第3张图片

2. 分布式锁

2.1 基本原理和实现方式对比

分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。

分布式锁的核心思想就是让大家都使用同一把锁,只要大家使用的是同一把锁,那么我们就能锁住线程,不让线程进行,让程序串行执行,这就是分布式锁的核心思路

springboot整合redis 分布式秒杀优化_第4张图片

那么分布式锁他应该满足一些什么样的条件呢?

  • 可见性:多个线程都能看到相同的结果,注意:这个地方说的可见性并不是并发编程中指的内存可见性,只是说多个进程之间都能感知到变化的意思

  • 互斥:互斥是分布式锁的最基本的条件,使得程序串行执行

  • 高可用:程序不易崩溃,时时刻刻都保证较高的可用性

  • 高性能:由于加锁本身就让性能降低,所有对于分布式锁本身需要他就较高的加锁性能和释放锁性能

  • 安全性:安全也是程序中必不可少的一环
    springboot整合redis 分布式秒杀优化_第5张图片

常见的分布式锁有三种

Mysql:mysql 本身就带有锁机制,但是由于 mysql 性能本身一般,所以采用分布式锁的情况下,其实使用 mysql 作为分布式锁比较少见

Redis:redis 作为分布式锁是非常常见的一种使用方式,现在企业级开发中基本都使用 redis 或者 zookeeper 作为分布式锁,利用 setnx 这个方法,如果插入 key 成功,则表示获得到了锁,如果有人插入成功,其他人插入失败则表示无法获得到锁,利用这套逻辑来实现分布式锁

Zookeeper:zookeeper 也是企业级开发中较好的一个实现分布式锁的方案,由于本套视频并不讲解 zookeeper 的原理和分布式锁的实现,所以不过多阐述
springboot整合redis 分布式秒杀优化_第6张图片

2.2 、Redis 分布式锁的实现核心思路

实现分布式锁时需要实现的两个基本方法:

  • 获取锁:
    • 互斥:确保只能有一个线程获取锁
    • 非阻塞:尝试一次,成功返回 true,失败返回 false
      .
  • 释放锁:
    • 手动释放
    • 超时释放:获取锁时添加一个超时时间
      在这里插入图片描述

核心思路:

我们利用 redis 的 setNx 方法,当有多个线程进入时,我们就利用该方法,第一个线程进入时,redis 中就有这个 key 了,返回了 1,如果结果是 1,则表示他抢到了锁,那么他去执行业务,然后再删除锁,退出锁逻辑,没有抢到锁的哥们,等待一定时间后重试即可。

springboot整合redis 分布式秒杀优化_第7张图片

2.3 实现分布式锁版本一

锁的基本接口

public interface ILock {

    /**
     *  尝试获取锁
     *  timeoutSec锁的超时时间,过期自动释放
     */
    boolean tryLock(long timeoutSec);

    /**
     *  释放锁
     */
    void unlock();
}

SimpleRedisLock

利用 setnx 方法进行加锁,同时增加过期时间,防止死锁,此方法可以保证加锁和增加过期时间具有原子性

private static final String KEY_PREFIX="lock:"

@Override
public boolean tryLock(long timeoutSec) {
    // 获取线程标示
    String threadId = Thread.currentThread().getId()
    // 获取锁
    Boolean success = stringRedisTemplate.opsForValue()
            .setIfAbsent(KEY_PREFIX + name, threadId + "", timeoutSec, TimeUnit.SECONDS);
    return Boolean.TRUE.equals(success);
}

public void unlock() {
    //通过del删除锁
    stringRedisTemplate.delete(KEY_PREFIX + name);
}

修改业务代码

@Override
  public Result seckillVoucher(Long voucherId) {
      // 1.查询优惠券
      SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
      // 2.判断秒杀是否开始
      if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
          // 尚未开始
          return Result.fail("秒杀尚未开始!");
      }
      // 3.判断秒杀是否已经结束
      if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
          // 尚未开始
          return Result.fail("秒杀已经结束!");
      }
      // 4.判断库存是否充足
      if (voucher.getStock() < 1) {
          // 库存不足
          return Result.fail("库存不足!");
      }
      Long userId = UserHolder.getUser().getId();
      //创建锁对象(新增代码)
      SimpleRedisLock lock = new SimpleRedisLock("order:" + userId, stringRedisTemplate);
      //获取锁对象
      boolean isLock = lock.tryLock(1200);
//加锁失败
      if (!isLock) {
          return Result.fail("不允许重复下单");
      }
      try {
          //获取代理对象(事务)
          IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
          return proxy.createVoucherOrder(voucherId);
      } finally {
          //释放锁
          lock.unlock();
      }
  }

2.4 Redis 分布式锁误删情况说明

逻辑说明:

持有锁的线程在锁的内部出现了阻塞,导致他的锁自动释放,这时其他线程,线程 2 来尝试获得锁,就拿到了这把锁,然后线程 2 在持有锁执行过程中,线程 1 反应过来,继续执行,而线程 1 执行过程中,走到了删除锁逻辑,此时就会把本应该属于线程 2 的锁进行删除,这就是误删别人锁的情况说明

解决方案:解决方案就是在每个线程释放锁的时候,去判断一下当前这把锁是否属于自己,如果属于自己,则不进行锁的删除,假设还是上边的情况,线程 1 卡顿,锁自动释放,线程 2 进入到锁的内部执行逻辑,此时线程 1 反应过来,然后删除锁,但是线程 1,一看当前这把锁不是属于自己,于是不进行删除锁逻辑,当线程 2 走到删除锁逻辑时,如果没有卡过自动释放锁的时间点,则判断当前这把锁是属于自己的,于是删除这把锁。

springboot整合redis 分布式秒杀优化_第8张图片

4.5 解决 Redis 分布式锁误删问题

需求:修改之前的分布式锁实现,满足:在获取锁时存入线程标示(可以用 UUID 表示)

在释放锁时先获取锁中的线程标示,判断是否与当前线程标示一致

  • 如果一致则释放锁
  • 如果不一致则不释放锁

核心逻辑:在存入锁时,放入自己线程的标识,在删除锁时,判断当前这把锁的标识是不是自己存入的,如果是,则进行删除,如果不是,则不进行删除。

springboot整合redis 分布式秒杀优化_第9张图片

SimpleRedisLock

private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";

//具体代码如下:加锁
@Override
public boolean tryLock(long timeoutSec) {
   // 获取线程标示
   String threadId = ID_PREFIX + Thread.currentThread().getId();
   // 获取锁
   Boolean success = stringRedisTemplate.opsForValue()
                .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
   return Boolean.TRUE.equals(success);
}

//释放锁
public void unlock() {
    // 获取线程标示
    String threadId = ID_PREFIX + Thread.currentThread().getId();
    // 获取锁中的标示
    String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
    // 判断标示是否一致
    if(threadId.equals(id)) {
        // 释放锁
        stringRedisTemplate.delete(KEY_PREFIX + name);
    }
}

有关代码实操说明:

在我们修改完此处代码后,我们重启工程,然后启动两个线程,第一个线程持有锁后,手动释放锁,第二个线程 此时进入到锁内部,再放行第一个线程,此时第一个线程由于锁的 value 值并非是自己,所以不能释放锁,也就无法删除别人的锁,此时第二个线程能够正确释放锁,通过这个案例初步说明我们解决了锁误删的问题。

4.6 分布式锁的原子性问题

更为极端的误删逻辑说明:

线程 1 现在持有锁之后,在执行业务逻辑过程中,他正准备删除锁,而且已经走到了条件判断的过程中,比如他已经拿到了当前这把锁确实是属于他自己的,正准备删除锁,但是此时他的锁到期了,那么此时线程 2 进来,但是线程 1 他会接着往后执行,当他卡顿结束后,他直接就会执行删除锁那行代码,相当于条件判断并没有起到作用,这就是删锁时的原子性问题,之所以有这个问题,是因为线程 1 的拿锁,比锁,删锁,实际上并不是原子性的,我们要防止刚才的情况发生,

springboot整合redis 分布式秒杀优化_第10张图片

❄️3. 分布式锁 - redission

3.1 分布式锁 - redission 功能介绍

基于 setnx 实现的分布式锁存在下面的问题:

  • 重入问题:重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中,可重入锁的意义在于防止死锁,比如 HashTable 这样的代码中,他的方法都是使用 synchronized 修饰的,假如他在一个方法内,调用另一个方法,那么此时如果是不可重入的,不就死锁了吗?所以可重入锁他的主要意义是防止死锁,我们的synchronized 和 Lock 锁都是可重入的。
  • 不可重试:是指目前的分布式只能尝试一次,我们认为合理的情况是:当线程在获得锁失败后,他应该能再次尝试获得锁。
  • 超时释放:我们在加锁时增加了过期时间,这样的我们可以防止死锁,但是如果卡顿的时间超长,虽然我们采用了 lua 表达式防止删锁的时候,误删别人的锁,但是毕竟没有锁住,有安全隐患
  • 主从一致性: 如果 Redis 提供了主从集群,当我们向集群写数据时,主机需要异步的将数据同步给从机,而万一在同步过去之前,主机宕机了,就会出现死锁问题。

springboot整合redis 分布式秒杀优化_第11张图片

那么什么是 Redission 呢

Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网格(In-Memory Data Grid)。它不仅提供了一系列的分布式的 Java 常用对象,还提供了许多分布式服务,其中就包含了各种分布式锁的实现。

Redission 提供了分布式锁的多种多样的功能

springboot整合redis 分布式秒杀优化_第12张图片

3.2 分布式锁 - Redission 快速入门

引入依赖:

<dependency>
	<groupId>org.redisson</groupId>
	<artifactId>redisson</artifactId>
	<version>3.13.6</version>
</dependency>

配置 Redisson 客户端:

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient(){
        // 配置
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.1.101:6379").setPassword("123456");
        // 创建RedissonClient对象
        return Redisson.create(config);
    }
}

4、秒杀优化

4.1 秒杀优化 - 异步秒杀思路

当用户发起请求,此时会请求 nginx,nginx 会访问到 tomcat,而 tomcat 中的程序,会进行串行操作,分成如下几个步骤

1、查询优惠卷

2、判断秒杀库存是否足够

3、查询订单

4、校验是否是一人一单

5、扣减库存

6、创建订单

springboot整合redis 分布式秒杀优化_第13张图片

优化方案:我们将耗时比较短的逻辑判断放入到 redis 中,比如是否库存足够,比如是否一人一单,这样的操作,只要这种逻辑可以完成,就意味着我们是一定可以下单完成的,我们只需要进行快速的逻辑判断,根本就不用等下单逻辑走完,我们直接给用户返回成功, 再在后台开一个线程,后台线程慢慢的去执行 queue 里边的消息,这样程序不就超级快了吗?而且也不用担心线程池消耗殆尽的问题,因为这里我们的程序中并没有手动使用任何线程池,当然这里边有两个难点

第一个难点是我们怎么在 redis 中去快速校验一人一单,还有库存判断

第二个难点是由于我们校验和 tomct 下单是两个线程,那么我们如何知道到底哪个单他最后是否成功,或者是下单完成,为了完成这件事我们在 redis 操作完之后,我们会将一些信息返回给前端,同时也会把这些信息丢到异步 queue 中去,后续操作中,可以通过这个 id 来查询我们 tomcat 中的下单逻辑是否完成了。

springboot整合redis 分布式秒杀优化_第14张图片
我们现在来看看整体思路:当用户下单之后,判断库存是否充足只需要导 redis 中去根据 key 找对应的 value 是否大于 0 即可,如果不充足,则直接结束,如果充足,继续在 redis 中判断用户是否可以下单,如果 set 集合中没有这条数据,说明他可以下单,如果 set 集合中没有这条记录,则将 userId 和优惠卷存入到 redis 中,并且返回 0,整个过程需要保证是原子性的,我们可以使用 lua 来操作

当以上判断逻辑走完之后,我们可以判断当前 redis 中返回的结果是否是 0 ,如果是 0,则表示可以下单,则将之前说的信息存入到到 queue 中去,然后返回,然后再来个线程异步的下单,前端可以通过返回的订单 id 来判断是否下单成功。

springboot整合redis 分布式秒杀优化_第15张图片

4.2 秒杀优化 - Redis 完成秒杀资格判断

需求:

  • 新增秒杀优惠券的同时,将优惠券信息保存到 Redis 中

  • 基于 Lua 脚本,判断秒杀库存、一人一单,决定用户是否抢购成功

  • 如果抢购成功,将优惠券 id 和用户 id 封装后存入阻塞队列

  • 开启线程任务,不断从阻塞队列中获取信息,实现异步下单功能

在这里插入图片描述
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中
    //SECKILL_STOCK_KEY 这个变量定义在RedisConstans中
    //private static final String SECKILL_STOCK_KEY ="seckill:stock:"
    stringRedisTemplate.opsForValue().set(SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());
}

完整 lua 表达式

-- 1.参数列表
-- 1.1.优惠券id
local voucherId = ARGV[1]
-- 1.2.用户id
local userId = ARGV[2]


-- 2.数据key
-- 2.1.库存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.订单key
local orderKey = 'seckill:order:' .. voucherId

-- 3.脚本业务
-- 3.1.判断库存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2.库存不足,返回1
    return 1
end
-- 3.2.判断用户是否下单 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在,说明是重复下单,返回2
    return 2
end
-- 3.4.扣库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下单(保存用户)sadd orderKey userId
redis.call('sadd', orderKey, userId)
return 0

以上 lua 表达式执行完毕后,剩下的就是根据步骤 3,4 来执行我们接下来的任务了

VoucherOrderServiceImpl

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

    @Resource
    private ISeckillVoucherService seckillVoucherService;

    @Resource
    private RedisIdWorker redisIdWorker;

    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Resource
    private RedissonClient redissonClient;

    private static final DefaultRedisScript<Long> SECKILL_SCRIPT;

    static {
        SECKILL_SCRIPT = new DefaultRedisScript<>();
        SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua"));
        SECKILL_SCRIPT.setResultType(Long.class);
    }

    private IVoucherOrderService proxy;

    // 当初始化完毕后,就会去从对列中去拿信息
    private BlockingQueue<VoucherOrder> orderTasks = new ArrayBlockingQueue<>(1024 * 1024);
    //异步处理线程池
    private static final ExecutorService SECKILL_ORDER_EXECUTOR = Executors.newSingleThreadExecutor();

    //在类初始化之后执行,因为当这个类初始化好了之后,随时都是有可能要执行的
    @PostConstruct
    private void init() {
        SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
    }

    private class VoucherOrderHandler implements Runnable {

        @Override
        public void run() {
            while (true) {
                try {
                    // 1.获取队列中的订单信息
                    VoucherOrder voucherOrder = orderTasks.take();
                    // 2.创建订单
                    handleVoucherOrder(voucherOrder);
                } catch (Exception e) {
                    log.error("处理订单异常", e);
                }
            }
        }
    }


    private void handleVoucherOrder(VoucherOrder voucherOrder) {
        //1.获取用户
        Long userId = voucherOrder.getUserId();
        // 2.创建锁对象
        RLock redisLock = redissonClient.getLock("lock:order:" + userId);
        // 3.尝试获取锁
        boolean isLock = redisLock.tryLock();
        // 4.判断是否获得锁成功
        if (!isLock) {
            // 获取锁失败,直接返回失败或者重试
            log.error("不允许重复下单!");
            return;
        }
        try {
            //注意:由于是spring的事务是放在threadLocal中,此时的是多线程,事务会失效
            proxy.createVoucherOrder(voucherOrder);
        } finally {
            // 释放锁
            redisLock.unlock();
        }
    }


    @Override
        public Result seckillVoucher(Long voucherId) {
            Long userId = UserHolder.getUser().getId();
        // 1.执行lua脚本
            Long result = stringRedisTemplate.execute(
                    SECKILL_SCRIPT,
                    Collections.emptyList(),
                    voucherId.toString(), userId.toString()
            );
            int r = result.intValue();
            // 2.判断结果是否为0
            if (r != 0) {
                // 2.1.不为0 ,代表没有购买资格
                return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
            }
            // 2.2.为0 ,有购买资格,把下单信息保存到阻塞队列
            VoucherOrder voucherOrder = new VoucherOrder();
            // 2.3.订单id
            long orderId = redisIdWorker.nextId("order");
            voucherOrder.setId(orderId);
            // 2.4.用户id
            voucherOrder.setUserId(userId);
            // 2.5.代金券id
            voucherOrder.setVoucherId(voucherId);
            // 2.6.放入阻塞队列
            orderTasks.add(voucherOrder);
            // 3.获取代理对象
            proxy = (IVoucherOrderService) AopContext.currentProxy();
            // 4.返回订单id
            return Result.ok(orderId);
        }


        @Transactional
        @Override
        public void createVoucherOrder(VoucherOrder voucherOrder) {
            Long userId = voucherOrder.getUserId();
            // 5.1.查询订单
            int count = Math.toIntExact(query().eq("user_id", userId).eq("voucher_id", voucherOrder).count());
            // 5.2.判断是否存在
            if (count > 0) {
                // 用户已经购买过了
                log.error("不允许重复下单!");
                return;
            }

            // 6.扣减库存
            boolean success = seckillVoucherService.update()
                    .setSql("stock = stock - 1") // set stock = stock - 1
                    .eq("voucher_id", voucherOrder).gt("stock", 0) // where id = ? and stock > 0
                    .update();
            if (!success) {
                // 扣减失败
                log.error("库存不足!");
                return;
            }

            // 7.创建订单
            save(voucherOrder);

    }

}

小结

通过加锁可以解决在分布式环境下的秒杀安全问题,并对此使用阻塞队列分布式锁Redission分布式锁对业务功能进行优化.

如果这篇【文章】有帮助到你,希望可以给我点个赞,创作不易,如果有对Java后端或者对redis感兴趣的朋友,请多多关注

个人主页
谱尼学java

你可能感兴趣的:(redis,官方学习,spring,boot,redis,分布式)