黑马点评4——优惠券秒杀—分布式锁

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

文章目录


接上篇，在集群模式下，synchronized锁失效了
在这里插入图片描述
得让多个JVM监视器都能使用这个外部的锁才行——这就是分布式锁。

分布式锁

在这里插入图片描述
关键是让多个JVM进程都能看见这个锁

什么是分布式锁

在这里插入图片描述

分布式锁的实现

在这里插入图片描述

基于redis实现分布式锁

在这里插入图片描述
但这种方案在获取锁以后，要是服务宕机了，那就无法释放锁了，所以我们采用下面的方法：

在这里插入图片描述
在这里插入图片描述

分布式锁初级版本

先写一个分布式锁的接口

package com.hmdp.utils;

public interface ILock {

    /**
     * 尝试获取锁
     * @param timeoutSec
     * @return
     */
    boolean tryLock(long timeoutSec);


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

在写一个实现类

package com.hmdp.utils;

import org.springframework.data.redis.core.StringRedisTemplate;

import java.util.concurrent.TimeUnit;

public class SimpleRedisLock implements ILock{

    private String name;
    private StringRedisTemplate stringRedisTemplate;

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

    private static final String KEY_PREFIX = "lock:";

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

    @Override
    public void unlock() {
        // 释放锁
        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("秒杀尚未开始！");
        }
        // 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);  // 报错了是因为我们的接口中没有这个方法，那我们就在接口中创建一下这个方法
        }*/
        // 创建锁对象-初版分布式锁
        SimpleRedisLock lock = new SimpleRedisLock("oder:" + userId, stringRedisTemplate);
        // 获取锁
        boolean isLock = lock.tryLock(1200L);
        // 判断是否获取锁成功
        if(!isLock){
            // 获取锁失败，返回错误信息或重试
            return Result.fail("不允许重复下单！");
        }
        try{
// 获取代理对象（事务）
            IVoucherOrderService proxy = (IVoucherOrderService)AopContext.currentProxy();  // 拿到当前对象的代理对象，其实就是IVoucherOrderService这个接口的代理对象，返回的是Object，做个强转
            return proxy.createVoucherOrder(voucherId);  // 报错了是因为我们的接口中没有这个方法，那我们就在接口中创建一下这个方法
        }finally{
            // 释放锁
            lock.unlock();
        }
    }

现在测试，我们就可以看见一个用户获取了锁之后，另一个用户就无法再次获取锁了。

redis分布式锁的误删问题

这种方案一般情况下没问题，但是有些情况下会有问题：
线程1如果因为某种原因业务产生阻塞，锁的持有周期就变长，如果阻塞的太长时间，超过了我们设置锁的超时时间，
在这里插入图片描述
业务还没结束，锁提前释放，其他的线程就可以获得锁，这就出现问题

在这里插入图片描述
当线程二拿到锁了之后，线程1的任务结束了，开始去释放锁，这时候线程1把线程2的锁给释放了。
线程3又来了，又再次拿到锁
在这里插入图片描述
这种极端情况产生的原因，其一：业务阻塞导致锁提前释放，其二：线程1把别人的线程的锁释放了
那怎么避免呢，我们往redis中存锁的时候，存了线程标识进去了，那我们释放锁的时候，把这个标识利用起来，就可以避免问题的发生。
在这里插入图片描述
因此业务流程就要变化，获取锁的时候， 要把线程标识存进去，释放锁的时候，要判断这个标识是不是自己。
在这里插入图片描述
我们只需要需改我们的锁的实现类


public class SimpleRedisLock implements ILock{

    private String name;
    private StringRedisTemplate stringRedisTemplate;

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

    private static final String KEY_PREFIX = "lock:";
    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);
    }

    @Override
    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);
        }
    }
}

这次测试就发现锁的误删就解决了
但是还有问题：

分布式锁的原子性问题

在这里插入图片描述
问题简单描述，线程1在释放锁的时候判断锁是不是自己的，判断是自己的，然后准备删除锁的时候，这时候由于JVM垃圾回收等原因，导致了我们的线程1被阻塞了，好巧不巧，这时候锁超时了，自动释放了，然后线程2来了，获取了锁开始执行线程2的任务，然后线程1这时候反应过来了，他不知道锁已经释放了，他还记得自己就是锁的主人，然后，反手就把线程2的锁释放了，然后这时候线程3来了，又可以获取锁了，这不就出问题了。
那这次又因为什么出问题了呢？就因为，我们的判断和释放是两个动作，这两个动作之间产生了阻塞，产生了问题，那我们想避免这样的问题，就得让判断和释放的动作都是原子性的动作。

lua脚本解决多条命令原子性问题

Redis脚本提供了脚本功能，在一个脚本中编写多条Redis命令，确保多条命令执行的原子性。lua脚本是一种编程语言。
lua教程
在这里插入图片描述在这里插入图片描述

在这里插入图片描述
先把脚本写出来

-- 获取锁中的线程标识 get key
local id = redis.call('get', KEYS[1])
-- 比较线程标识和锁中的标识是否一致
if(id == ARGV[1]) then
	-- 释放锁 del key
	return redis.call('del', KEYS[1])
end
-- 不一致，则直接返回
return 0

Java调用lua脚本改进redis的分布式锁

在这里插入图片描述

则我们的分布式锁的实现代码可以改成这样：

package com.hmdp.utils;

import cn.hutool.core.lang.UUID;

import org.springframework.core.io.ClassPathResource;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;

import java.util.Collections;
import java.util.concurrent.TimeUnit;

public class SimpleRedisLock implements ILock{

    private String name;
    private StringRedisTemplate stringRedisTemplate;
    // 我们提前把脚本准备好，这样每次使用的时候不用在去读脚本文件，减少IO
    private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
    static {
        UNLOCK_SCRIPT = new DefaultRedisScript<>();
        UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
        UNLOCK_SCRIPT.setResultType(Long.class);
    }

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

    private static final String KEY_PREFIX = "lock:";
    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);
    }

    @Override
    public void unlock(){
        // 调用lua脚本
        stringRedisTemplate.execute(
                UNLOCK_SCRIPT,
                Collections.singletonList(KEY_PREFIX + name),
                ID_PREFIX + Thread.currentThread().getId());
    }

   /* @Override
    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);
        }
    }*/


}

把lua脚本放在文件读取

-- 获取锁中的线程标识 get key
local id = redis.call('get', KEYS[1])
-- 比较线程标识和锁中的标识是否一致
if(id == ARGV[1]) then
	-- 释放锁 del key
	return redis.call('del', KEYS[1])
end
-- 不一致，则直接返回
return 0

通过lua脚本的执行，实现判断和执行的原子性。

总结
在这里插入图片描述
这样就保障了我们的分布式锁的相对可靠，但还有问题

分布式锁-Redisson功能介绍

目前我们实现的分布式锁的问题如下：
在这里插入图片描述

在这里插入图片描述
官网地址
github地址

分布式锁-Redisson快速入门

在这里插入图片描述

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

@Configuration
public class RedissonConfig {

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

不推荐使用springBoot整合Redisson的starter使用，因为他会替代我们Spring官方提供的对于Redis的配置和实现。所以使用分布式锁的时候，自己来配置Redisson更值得推荐。
在这里插入图片描述
来改造我们的获取锁的业务代码


    @Autowired
    private RedissonClient redissonClient;
    @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);  // 报错了是因为我们的接口中没有这个方法，那我们就在接口中创建一下这个方法
        }*/
        // 创建锁对象-初版分布式锁
//        SimpleRedisLock lock = new SimpleRedisLock("oder:" + userId, stringRedisTemplate);
        RLock lock = redissonClient.getLock("lock:oder:" + userId);  // 使用Redisson获取锁
        // 获取锁
//        boolean isLock = lock.tryLock(1200L);
        boolean isLock = lock.tryLock();
        // 判断是否获取锁成功
        if(!isLock){
            // 获取锁失败，返回错误信息或重试
            return Result.fail("不允许重复下单！");
        }
        try{
// 获取代理对象（事务）
            IVoucherOrderService proxy = (IVoucherOrderService)AopContext.currentProxy();  // 拿到当前对象的代理对象，其实就是IVoucherOrderService这个接口的代理对象，返回的是Object，做个强转
            return proxy.createVoucherOrder(voucherId);  // 报错了是因为我们的接口中没有这个方法，那我们就在接口中创建一下这个方法
        }finally{
            // 释放锁
            lock.unlock();
        }
    }

Redisson可重入原理

在这里插入图片描述

可重入其实就是在尝试获取锁的时候判断一下是不是自己本身拿着锁，要是自己拿着锁，就可以获取，给重入标识+1
因此不仅记录线程标识，还要记录一个重入次数，那使用这个string类型的数据结构就不行了，那就得使用hash结构，因为hash结构可以保存多个键值对。
但用了hash之后就没了nx ex这样的指令了，所以只能分开做，先判断锁存在不存在，如果锁不存在那就获取锁并且添加线程标识，在设置有效期。
但要是锁已经存在的话，判断一下是不是自己的锁，要是判断发现是自己的锁，那就是重入。
在这里插入图片描述
现在为了实现锁的可重入，逻辑明显变得复杂了，就不能使用Java代码来实现了，那就必须要通过lua脚本来实现了。
获取lua脚本如下：

local key = KEYS[1];   -- 锁的key
local threadId = ARGV[1];   -- 线程的唯一标识
local releaseTime = ARGV[2];  -- 锁的自动释放时间
-- 判断是否存在
if(redis.call('exists',key) == 0) then 
	-- 不存在， 获取锁
	redis.call('hset', key, threadId, '1');
	-- 设置有效期
	redis.call('expire', key, releaseTime);
	return 1;   -- 返回结果
end；
-- 锁已经存在，判断threadId是否是自己
if(redis.call('hexists', key, threadId) == 1) then
	-- 不存在， 获取锁，重入次数+1；
	redis.call('hincrby', key, threadId, '1');
	-- 设置有效期
	redis.call('expire',key, releaseTime);
end;
return 0;  -- 代码走到这里，说明获取锁的不是自己，获取锁失败

释放锁的lua脚本：

local key = KEYS[1];  -- 锁的key
local threadId = ARGV[1];  -- 线程的唯一标识
local releaseTime = ARGV[2];  -- 锁的自动释放时间
-- 判断当前锁是否还是被自己持有
if(redis.call('HEXISTS', key, threadId) == 0)	then
	return nil;  -- 如果已经不是自己，则直接返回
end;
-- 是自己的锁，则重入次数-1；
local count = redis.call('HINCRBY', key, threadId, -1);
-- 判断是否重入次数是否已经为0
if(count > 0) then
	-- 大于0说明不能释放锁，重置有效期然后返回
	redis.call('EXPIRE', key, releaseTime);
	return nil;
else  -- 等于0 说明可以释放锁，直接删除
	redis.call('DEL', key);
	return nil;
end;

可以追踪redisson的源码看到

Redisson的锁重试和WatchDog机制

追踪源码
在这里插入图片描述
在这里插入图片描述

Redisson的multiLock原理

这主要是针对redis的主从一致性导致锁失效的问题
在这里插入图片描述
那redis说，既然是主从的关系导致的锁失效，那我们就不要主从结构了，大家都当主，只有在每一个节点都拿到锁，才算获取锁成功。

在这里插入图片描述
这下不仅解决了主从一致性，而且保障了可用性，那想让可用性更强一点，那我们可以给节点建立主从关系

在这里插入图片描述
这样依旧可以保证我们的可用性，假设有一台主节点宕机了，在同步的过程中，有线程进来拿锁，但是因为还没有同步完成，这个线程拿不到全部主节点的锁，也就无法获取锁，也就不会出现锁失效的问题。
在这里插入图片描述
RedissonMultiLock源码追踪看一下。
在这里插入图片描述

shall_zhao
关注
专栏目录
分布式锁
qq_36335126的博客
08-04 468
分布式锁 1.1 什么是分布式锁 当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数。 与单机模式下的锁不仅需要保证进程可见，还需要考虑进程与锁之间的网络问题。（我觉得分布式情况下之所以问题变得复杂，主要就是需要考虑到网络的延时和不可靠。） 分布式锁还是可以将标记存在内存，只是该内存不是某个进程分配的内存而是公共内存如 Redis、Memcache。至于利用数据库、文件等做锁与单机的实现是一样的，只要保证标记能互斥就行。 1.2 分布式锁场景 1.
Java项目——黑马点评（优惠券秒杀5之分布式锁）
做一个善良的人，做好自己的事，如果愿意，再发一份光。
03-22 1286
因为上面的流程判断锁与释放锁不在同一时刻，在这中间由于JVM的垃圾回收策略等会导致代码执行阻塞，也许又会有执行时间大于EX时间的情况发生，就又出现了上面的多线程并发安全问题。在之前实现的锁已经能够满足大多数的场景，但是还有可以提升的空间。如下——有Redisson成熟框架下的支持——Redisson——在Redis基础下实现的分布式工具集合**（分布式锁是它的子集）**#主从节点总共讲了三种锁，层层递进——
深入理解分布式锁
最新发布
爱新觉罗ZBC
09-04 895
分布式锁是一种在分布式系统环境下，多个节点对共享资源进行访问控制的同步机制。他的主要目的是保证同一时刻只有一个节点对共享资源进行操作，避免数据的不一致性。
黑马点评-优惠券秒杀
weixin_57393590的博客
10-16 932
redis分布式锁
黑马Redis实战项目——黑马点评笔记04 | 优惠券秒杀
2301_77450803的博客
04-25 1089
使用postman添加秒杀券//秒杀券信息 {
【Redis】Redis实战：黑马点评之优惠券秒杀
qq_50675319的博客
09-19 1357
每个店铺都可以发布优惠券：当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：id的规律性太明显如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。受单表数据量的限制。
Redis实战(黑马点评) 分布式锁 redission
m0_59166421的博客
09-20 253
重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。超时释放：我们在加锁时增加了过期时间，这样的我们可以防
黑马点评详细总结（问题 + 踩坑点 + 解决思路）
06-15
在"黑马点评详细总结"这个项目中，我们关注的是一个类似大众点评的平台，它大量使用了Redis这一内存数据存储系统。项目的主要功能包括短信登录和注册，以及相关的用户验证流程。以下是对这些关键知识点的详细说明： ...
《我想进大厂》之分布式锁夺命连环9问 | 大理版人在囧途
艾小仙的专栏
03-08 1777
开个头，这是篇技术文章，但是昨天一天太恶心了，忍不住还是简单说下昨天的事情。昨天早上11点飞大理，结果9点钟要出门的时候发现密码锁坏了，不用密码都能打开，一边司机师傅在催着走，一边连忙打电...
黑马点评redis分布式锁
10-24
黑马点评中使用了Redisson可重入锁来实现分布式锁，这种锁可以在多个Redis节点上同时进行setnx操作，只有所有节点都成功时才能获取锁。该分布式锁实现了ILock接口，其中tryLock方法尝试获取锁并设置锁的超时时间，unlock方法用于释放锁。使用Redis分布式锁可以实现多进程可见并且互斥的锁，保证了在分布式系统或集群模式下的数据一致性和并发控制。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值