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

---

前言

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

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

---

分布式锁要满足的条件：

● 多进程互斥：同一时刻，只有一个进程可以获取锁
● 保证锁可以释放：任务结束或出现异常，锁一定要释放，避免死锁
● 阻塞锁（可选）：获取锁失败时可否重试
● 重入锁（可选）：获取锁的代码递归调用时，依然可以获取锁

Redis分布式锁：

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

1. 在Redis中，利用Redis的setnx命令，这个命令的特征时如果多次执行，只有第一次执行会成功，可以实现互斥的效果。这满足了多线程互斥的要求。

SETNX lock thread1

2. 在Redis中，利用Redis的del命令，可以删除一个key,即释放锁。

DEL lock

3. 如果获取锁成功后服务宕机，发生了不释放锁的问题，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>

2. 配置Redis端口信息

Spring:
	redis:
	    port: 6379
	    host: localhost

3. 构造加锁工具类

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");
    }
}

4. 在实际秒杀业务代码上加锁、解锁

@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：

秒杀记录：

节点拓展后的三个秒杀服务：



三个服务都共同通过负载均衡消费了请求！

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

成功撒花！

---