分布式锁-----基于Reids实现（案例：黑马点评）

今天你写代码了吗？？

已于 2023-07-07 21:07:51 修改

阅读量64

点赞数

分类专栏：黑马点评 Redis 文章标签：分布式 lua

于 2023-07-06 18:22:23 首次发布

本文链接：https://blog.csdn.net/weixin_45618869/article/details/131577616

版权

Redis 同时被 2 个专栏收录

13 篇文章 0 订阅

订阅专栏

黑马点评

10 篇文章 0 订阅

订阅专栏

分布式锁的各种实现方式对比

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

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

可以很好的解决一人一单在多服务下出现的实效问题一人一单在夸服务下的锁的失效问题

在这里插入图片描述
分布式锁满足的条件：

可见性：多个线程都能看到相同的结果，注意：这个地方说的可见性并不是并发编程中指的内存可见性，只是说多个进程之间都能感知到变化的意思
互斥：互斥是分布式锁的最基本的条件，使得程序串行执行
高可用：程序不易崩溃，时时刻刻都保证较高的可用性
高性能：由于加锁本身就让性能降低，所有对于分布式锁本身需要他就较高的加锁性能和释放锁性能
安全性：安全也是程序中必不可少的一环

在这里插入图片描述
常见的分布式锁有三种:

Mysql：mysql本身就带有锁机制，但是由于mysql性能本身一般，所以采用分布式锁的情况下，其实使用mysql作为分布式锁比较少见
Redis：redis作为分布式锁是非常常见的一种使用方式，现在企业级开发中基本都使用redis或者zookeeper作为分布式锁，利用setnx这个方法，如果插入key成功，则表示获得到了锁，如果有人插入成功，其他人插入失败则表示无法获得到锁，利用这套逻辑来实现分布式锁
Zookeeper：zookeeper也是企业级开发中较好的一个实现分布式锁的方案，由于本套视频并不讲解zookeeper的原理和分布式锁的实现，所以不过多阐述

在这里插入图片描述

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

在这里插入图片描述

核心思路：

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

实现分布式锁版本一

定义锁的基本接口：

public interface ILock {
    /**
     * 获取锁
     * @param timeoutSec  锁持有的超时时间，过期后自动释放锁
     * @return true 代表获取锁成功   false 代表获取锁失败
     */
    boolean tryLock(long timeoutSec);

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

SimpleRedisLock实现接口，在里面实现上锁和释放锁的方法

public class SimpleRedisLock implements ILock{

     private  String name ;
        //给锁加上前缀  便于标识
     private static final String KEY_PREFIX="lock:";

     private StringRedisTemplate stringRedisTemplate;


     //构造器  用于将 name   stringRedisTemplate  注入进来
    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    /**
     *
     * @param timeoutSec  锁持有的超时时间，过期后自动释放锁
     * @return
     */
    @Override
    public boolean tryLock(long timeoutSec) {
        // 获取线程标示
        String threadId = String.valueOf(Thread.currentThread().getId());
        // 获取锁
        Boolean success = stringRedisTemplate.opsForValue()
                .setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
        //因为返回值是boolean  success是包装类  存在自动拆箱
        // 防止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("秒杀尚未开始！");
        }
        // 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();
        }
    }

这样通过 boolean isLock = lock.tryLock(1200); 拿到的锁监视器可以作用于不同的服务，并且在同一用户的请求下，发送到不同的Tomcat服务器上所执行的锁操作都是同一把锁（避免了synchronized只作用一台tomcat服务器或者jvm），这样可以实现同一用户在多个服务下也能实现一人一单的业务。

Redis分布式锁误删情况说明（极端情况下）

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

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

在这里插入图片描述

也就是给每一把锁加上标识，在各自的业务走完的时候一个去判断一下看看这把锁是不是自己加的，A只能删除A的锁，不能删除B的锁，这样就可以解决A在业务卡顿时，导致锁的超时删除，B开始业务时加了自己的业务锁，当A执行完业务要释放锁时判断锁的标识是不是自己的，不是则不能删除B的锁。

在这里插入图片描述

解决Redis分布式锁误删问题

需求：修改之前的分布式锁实现，满足：在获取锁时存入线程标示（可以用UUID表示）
在释放锁时先获取锁中的线程标示，判断是否与当前线程标示一致

为什么使用uuid呢因为在多个jvm中可能会出现相同线程id，会发生冲突，可以通过线程id和UUID进行拼接来作为锁的唯一标识

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

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

改造上锁的方法代码

 //给线程拼接上uuid  用来区分不同的jvm（不同服务）导致的线程id相同带来的冲突
     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);
        //因为返回值是boolean  success是包装类  存在自动拆箱
        // 防止success为空造成空指针异常
    }

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

分布式锁的原子性问题

上述情况好像是解决锁的误删问题了，但是再考虑一种极端的问题：

在这里插入图片描述

因为这里的判断和释放锁是两个动作，先判断在释放锁，如果在A线程业务完成进行判断之后验证是自己的锁，然后即将去释放锁的时候，出现了阻塞的情况（可能因为jvm的垃圾回收的机制等等阻塞了一段时间），自己的锁在阻塞的这一段时间超时了就被释放了，那么这个时候突然B线程也开启了自己的业务，加了一把自己的锁，在B线程还未完成业务释放锁之前，当A线程突然活了（之前已经做过锁标识的判断，误认为B加的锁还是自己的）,这个时候A就会把B的锁删掉，这就是删锁时的原子性问题，之所以有这个问题，是因为线程A的拿锁，比锁，删锁，实际上并不是原子性的，我们要防止刚才的情况发生，

在这里插入图片描述
Lua脚本解决多条命令原子性问题

lua脚本的基本使用参考链接：基于 Redis + Lua 脚本实现分布式锁，确保操作的原子性

先在resources下定义好lua脚本
在这里插入图片描述

RedisTemplate中，可以利用execute方法去执行lua脚本，参数对应关系就如下图股

在这里插入图片描述
代码实现：

//提前初始化脚本，避免每次去执行脚本时单独去创建脚本对象
private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
    static {
        UNLOCK_SCRIPT = new DefaultRedisScript<>();
        UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
        UNLOCK_SCRIPT.setResultType(Long.class);
    }
//用lua脚本来保持分布式锁的原子性
public void unlock() {
    // 调用lua脚本
    stringRedisTemplate.execute(
            UNLOCK_SCRIPT,
            Collections.singletonList(KEY_PREFIX + name),
            ID_PREFIX + Thread.currentThread().getId());
}
经过以上代码改造后，我们就能够实现 拿锁比锁删锁的原子性动作了~

基于Redis的分布式锁实现思路：
*利用set nx ex获取锁，并设置过期时间，保存线程标示
*释放锁时先判断线程标示是否与自己一致，一致则删除锁
*特性：
* 利用set nx满足互斥性
* 利用set ex保证故障时锁依然能释放，避免死锁，提高安全性
* 利用Redis集群保证高可用和高并发特性
笔者总结我们一路走来，利用添加过期时间，防止死锁问题的发生，但是有了过期时间之后，可能出现误删别人锁的问题，这个问题我们开始是利用删之前通过拿锁，比锁，删锁这个逻辑来解决的，也就是删之前判断一下当前这把锁是否是属于自己的，但是现在还有原子性问题，也就是我们没法保证拿锁比锁删锁是一个原子性的动作，最后通过lua表达式来解决这个问题

今天你写代码了吗？？

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
分布式锁-----基于Reids实现（案例：黑马点评）

分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁。:就是让大家都使用同一把锁，只要大家使用的是，那么我们就能锁住线程，不让线程进行，让程序串行执行，这就是分布式锁的核心思路。可以很好的解决一人一单在多服务下出现的实效问题多个线程都能看到相同的结果，注意：这个地方说的可见性并不是并发编程中指的内存可见性，只是说多个进程之间都能感知到变化的意思互斥是分布式锁的最基本的条件，使得程序串行执行程序不易崩溃，时时刻刻都保证较高的可用性。
复制链接

扫一扫