秒杀场景下用Redis分布式锁解决超卖问题


前言

超卖问题通常出现在多用户并发操作的情况下,即多个用户尝试购买同一件商品,导致商品库存不足或者超卖。解决超卖问题的方法有很多:乐观锁、Redis分布式锁、消息队列等。
分布式锁是一种多节点共享的同步机制,通过在多个节点之间协调访问资源,确保在同一时间只有一个节点能够获取锁并执行关键操作。在电商网站中,可以将每个商品的库存作为共享资源,使用分布式锁来控制并发访问。

在这里插入图片描述
分布式锁的目的是保证在分布式部署的应用集群中,多个服务在请求同一个方法或者同一个业务操作的情况下,对应业务逻辑只能被一台机器上的一个线程执行,避免出现并发问题。


分布式锁要满足的条件:

● 多进程互斥:同一时刻,只有一个进程可以获取锁
● 保证锁可以释放:任务结束或出现异常,锁一定要释放,避免死锁

● 阻塞锁(可选):获取锁失败时可否重试
● 重入锁(可选):获取锁的代码递归调用时,依然可以获取锁

Redis分布式锁:

在实现Redis分布式锁之前,我们先来看看为什么Redis能实现分布式锁:

  1. 在Redis中,利用Redis的setnx命令,这个命令的特征时如果多次执行,只有第一次执行会成功,可以实现互斥的效果。这满足了多线程互斥的要求
SETNX lock thread1
  1. 在Redis中,利用Redis的del命令,可以删除一个key,即释放锁。
DEL lock
  1. 如果获取锁成功后服务宕机,发生了不释放锁的问题,Redis也可以通过给Key加有效时间,让超时自动释放。这样一来,也满足了保证锁可以释放,达到了分布式锁必须满足的条件!
EXPIRE lock 10  

并且,也不用担心在EXPIRE设置有效期之前服务宕机,Redis的set命令可以满足setnx和expirr的原子性,用一个指令完成两个步骤!

set lock thread1 EX 10 NX

分布式架构中实现

  1. 加Redis坐标
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
  1. 配置Redis端口信息
Spring:
	redis:
	    port: 6379
	    host: localhost
  1. 构造加锁工具类
public interface ILock {
    /**
     * 尝试获取锁
     * @param timeoutSec 锁持有的超时时间,过期后自动释放
     * @return true代表获取锁成功; false代表获取锁失败
     */
    boolean tryLock(long timeoutSec);
    /**
     * 释放锁
     */
    void unlock();
}
public class SimpleRedisLock implements ILock  {

    private StringRedisTemplate stringRedisTemplate;

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

    @Override
    public boolean tryLock(long timeoutSec) {

        Boolean secuss = stringRedisTemplate.opsForValue()
                .setIfAbsent("lock", "thread", timeoutSec, TimeUnit.SECONDS);
        return secuss;
    }

    @Override
    public void unlock() {
        stringRedisTemplate.delete("lock");
    }
}
  1. 在实际秒杀业务代码上加锁、解锁
@PostMapping("/kill")
    public String executeSeckillProduct(int productId,int seckillCount){
        //获取锁对象
        SimpleRedisLock redisLock =new SimpleRedisLock(stringRedisTemplate);
        //尝试获取锁对象
        boolean isLock = redisLock.tryLock(1200);
        if(!isLock){
            return "获取锁失败";
        }
        Product product = productService.findByPid(productId);

        if(product.getStock()<seckillCount){
            return "库存不足";
        }

        product.setStock(product.getStock()-seckillCount);

        int row = productService.reduceInventory(product);

        if(row>0){
            //新增秒杀记录
            SeckillRecord record = new SeckillRecord();
            record.setPid(product.getPid());
            record.setCount(seckillCount);
            record.setPanme(product.getPname());
            record.setTime(new Timestamp(System.currentTimeMillis()));
            recodeService.save(record);
        }
        //释放锁
        redisLock.unlock();
        return "秒杀成功";
    }

测试

在测试Redis分布式锁之前,我先用了GetWay网关同意了API接口,由网关分发路由请求,通过OpenFegin实现通信并做到负载均衡效果,并对秒杀服务做了节点扩展,尽可能的模拟除了分布式架构:
网关配置:

server:
  port: 7000
spring:
  application:
    name: gateway-application
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
    gateway:
      discovery:
        locator:
          enabled: true
      routes:
        - id: reckill_route
          uri: lb://service-reckill
          order: 1
          predicates:
            - Path=/reckill-serv/**
          filters:
            - StripPrefix=1

先测试不加分布式锁的效果:
数据库库存:10
在这里插入图片描述
秒杀记录:0在这里插入图片描述
运行服务:
在这里插入图片描述
JMeter测试数据:每秒500个请求
在这里插入图片描述
JMeter端口信息:
在这里插入图片描述
测试结果:

库存还剩6个,消耗4个。
在这里插入图片描述
秒杀记录已经一片糊涂了:
在这里插入图片描述


加上分布式锁测试:
测试数据如上。
库存为0:
在这里插入图片描述
秒杀记录:
在这里插入图片描述

节点拓展后的三个秒杀服务:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
三个服务都共同通过负载均衡消费了请求!

但还要注意的一点是,对于锁的把控一定要按时释放,一次的不释放,可能都会导致后续请求无法成功!

成功撒花!


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值