首页 > 数据库 >面试官:Redis 分布式锁如何自动续期

面试官:Redis 分布式锁如何自动续期

时间:2023-10-12 13:04:21浏览次数:54  
标签:面试官 return threadId Redis long 获取 线程 time 续期


1、Redis 实现分布式锁

  • 指定一个 key 作为锁标记,存入 Redis 中,指定一个 唯一的用户标识作为 value。
  • 当 key 不存在时才能设置值,确保同一时间只有一个客户端进程获得锁,满足互斥性特性。
  • 设置一个过期时间,防止因系统异常导致没能删除这个 key,满足防死锁特性。
  • 当处理完业务之后需要清除这个 key 来释放锁,清除 key 时需要校验 value 值,需要满足只有加锁的人才能释放锁 。

2、问题

如果这个锁的过期时间是30秒,但是业务运行超过了30秒,比如40秒,当业务运行到30秒的时候,锁过期了,其他客户端拿到了这个锁,怎么办

我们可以设置一个合理的过期时间,让业务能够在这个时间内完成业务逻辑,但LockTime的设置原本就很不容易。

  • LockTime设置过小,锁自动超时的概率就会增加,锁异常失效的概率也就会增加;
  • LockTime设置过大,万一服务出现异常无法正常释放锁,那么出现这种异常锁的时间也就越长。

我们只能通过经验去配置,一个可以接受的值,基本上是这个服务历史上的平均耗时再增加一定的buff。总体来说,设置一个合理的过期时间并不容易

我们也可以不设置过期时间,让业务运行结束后解锁,但是如果客户端出现了异常结束了或宕机了,那么这个锁就无法解锁,变成死锁;

3、自动续期

我们可以先给锁设置一个LockTime,然后启动一个守护线程,让守护线程在一段时间后,重新去设置这个锁的LockTime。

看起来很简单,但实现起来并不容易。

  • 和释放锁的情况一样,我们需要先判断持有锁客户端是否有变化。否则会造成无论谁持有锁,守护线程都会去重新设置锁的LockTime。
  • 守护线程要在合理的时间再去重新设置锁的LockTime,否则会造成资源的浪费。不能动不动就去续。
  • 如果持有锁的线程已经处理完业务了,那么守护线程也应该被销毁。不能业务运行结束了,守护者还在那里继续运行,浪费资源。

另外,关注公号“终码一生”,回复关键词“资料”,获取视频教程和最新的面试资料!

4、看门狗

Redisson的看门狗机制就是这种机制实现自动续期的

面试官:Redis 分布式锁如何自动续期_等待时间

Redissson tryLock

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
  long time = unit.toMillis(waitTime);
  long current = System.currentTimeMillis();
  long threadId = Thread.currentThread().getId();
  // 1.尝试获取锁
  Long ttl = tryAcquire(leaseTime, unit, threadId);
  // lock acquired
  if (ttl == null) {
    return true;
  }
  
  // 申请锁的耗时如果大于等于最大等待时间,则申请锁失败.
  time -= System.currentTimeMillis() - current;
  if (time <= 0) {
    acquireFailed(threadId);
    return false;
  }
  
  current = System.currentTimeMillis();
  
  /**
  * 2.订阅锁释放事件,并通过 await 方法阻塞等待锁释放,有效的解决了无效的锁申请浪费资源的问题:
  * 基于信息量,当锁被其它资源占用时,当前线程通过 Redis 的 channel 订阅锁的释放事件,一旦锁释放会发消息通知待等待的线程进行竞争.
  *
  * 当 this.await 返回 false,说明等待时间已经超出获取锁最大等待时间,取消订阅并返回获取锁失败.
  * 当 this.await 返回 true,进入循环尝试获取锁.
  */
  RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
  // await 方法内部是用 CountDownLatch 来实现阻塞,获取 subscribe 异步执行的结果(应用了 Netty 的 Future)
  if (!subscribeFuture.await(time, TimeUnit.MILLISECONDS)) {
    if (!subscribeFuture.cancel(false)) {
      subscribeFuture.onComplete((res, e) -> {
        if (e == null) {
          unsubscribe(subscribeFuture, threadId);
        }
      });
    }
    acquireFailed(threadId);
    return false;
  }
  
  try {
    // 计算获取锁的总耗时,如果大于等于最大等待时间,则获取锁失败.
    time -= System.currentTimeMillis() - current;
    if (time <= 0) {
      acquireFailed(threadId);
      return false;
  
    }
  
    /**
    * 3.收到锁释放的信号后,在最大等待时间之内,循环一次接着一次的尝试获取锁
    * 获取锁成功,则立马返回 true,
    * 若在最大等待时间之内还没获取到锁,则认为获取锁失败,返回 false 结束循环
    */
    while (true) {
      long currentTime = System.currentTimeMillis();
  
      // 再次尝试获取锁
      ttl = tryAcquire(leaseTime, unit, threadId);
      // lock acquired
      if (ttl == null) {
        return true;
      }
      // 超过最大等待时间则返回 false 结束循环,获取锁失败
      time -= System.currentTimeMillis() - currentTime;
      if (time <= 0) {
        acquireFailed(threadId);
        return false;
      }
  
      /**
      * 6.阻塞等待锁(通过信号量(共享锁)阻塞,等待解锁消息):
      */
      currentTime = System.currentTimeMillis();
      if (ttl >= 0 && ttl < time) {
        //如果剩余时间(ttl)小于wait time ,就在 ttl 时间内,从Entry的信号量获取一个许可(除非被中断或者一直没有可用的许可)。
        getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
      } else {
        //则就在wait time 时间范围内等待可以通过信号量
        getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
      }
  
      // 更新剩余的等待时间(最大等待时间-已经消耗的阻塞时间)
      time -= System.currentTimeMillis() - currentTime;
      if (time <= 0) {
        acquireFailed(threadId);
        return false;
      }
    }
  } finally {
    // 7.无论是否获得锁,都要取消订阅解锁消息
    unsubscribe(subscribeFuture, threadId);
  }
  return get(tryLockAsync(waitTime, leaseTime, unit));
}
  • 尝试获取锁,返回 null 则说明加锁成功,返回一个数值,则说明已经存在该锁,ttl 为锁的剩余存活时间。
  • 如果此时客户端 2 进程获取锁失败,那么使用客户端 2 的线程 id(其实本质上就是进程 id)通过 Redis 的 channel 订阅锁释放的事件。如果等待的过程中一直未等到锁的释放事件通知,当超过最大等待时间则获取锁失败,返回 false,也就是第 39 行代码。如果等到了锁的释放事件的通知,则开始进入一个不断重试获取锁的循环。
  • 循环中每次都先试着获取锁,并得到已存在的锁的剩余存活时间。如果在重试中拿到了锁,则直接返回。如果锁当前还是被占用的,那么等待释放锁的消息,具体实现使用了信号量 Semaphore 来阻塞线程,当锁释放并发布释放锁的消息后,信号量的 release() 方法会被调用,此时被信号量阻塞的等待队列中的一个线程就可以继续尝试获取锁了。
  • 当锁正在被占用时,等待获取锁的进程并不是通过一个 while(true) 死循环去获取锁,而是利用了 Redis 的发布订阅机制,通过 await 方法阻塞等待锁的进程,有效的解决了无效的锁申请浪费资源的问题。

另外,关注公号“终码一生”,回复关键词“资料”,获取视频教程和最新的面试资料!

5、看门狗如何自动续期

Redisson看门狗机制, 只要客户端加锁成功,就会启动一个 Watch Dog。

private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, long threadId) {
    if (leaseTime != -1) {
        return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
    }
    RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
    ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
        if (e != null) {
            return;
        }

        // lock acquired
        if (ttlRemaining == null) {
            scheduleExpirationRenewal(threadId);
        }
    });
    return ttlRemainingFuture;
}
  • leaseTime 必须是 -1 才会开启 Watch Dog 机制,如果需要开启 Watch Dog 机制就必须使用默认的加锁时间为 30s。
  • 如果你自己自定义时间,超过这个时间,锁就会自定释放,并不会自动续期。

6、续期原理

续期原理其实就是用lua脚本,将锁的时间重置为30s

private void scheduleExpirationRenewal(long threadId) {
    ExpirationEntry entry = new ExpirationEntry();
    ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);
    if (oldEntry != null) {
        oldEntry.addThreadId(threadId);
    } else {
        entry.addThreadId(threadId);
        renewExpiration();
    }
}

protected RFuture<Boolean> renewExpirationAsync(long threadId) {
    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
            "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                "return 1; " +
            "end; " +
            "return 0;",
        Collections.<Object>singletonList(getName()),
        internalLockLeaseTime, getLockName(threadId));
}
  • Watch Dog 机制其实就是一个后台定时任务线程,获取锁成功之后,会将持有锁的线程放入到一个 RedissonLock.EXPIR
     

标签:面试官,return,threadId,Redis,long,获取,线程,time,续期
From: https://blog.51cto.com/zhongmayisheng/7825692

相关文章

  • 面试官:MySQL数据查询太多会OOM吗
    我的主机内存只有100G,现在要全表扫描一个200G大表,会不会把DB主机的内存用光?逻辑备份时,可不就是做整库扫描吗?若这样就会把内存吃光,逻辑备份不是早就挂了?所以大表全表扫描,看起来应该没问题。这是为啥呢?1、全表扫描对server层的影响假设,我们现在要对一个200G的InnoDB表db1.t,执行一个......
  • 记一次Redis Cluster Pipeline导致的死锁问题
    作者:vivo互联网服务器团队-LiGang本文介绍了一次排查Dubbo线程池耗尽问题的过程。通过查看Dubbo线程状态、分析Jedis连接池获取连接的源码、排查死锁条件等方面,最终确认是因为使用了clusterpipeline模式且没有设置超时时间导致死锁问题。一、背景介绍RedisPipeline是一种高效......
  • 面试官:跨库多表存在大量数据依赖问题有哪些解决方案
    1、前言曾经设计的一个供应链系统中,存在商品、销售订单、采购这三个服务,它们的主数据的部分结构如下所示:商品:订单和子订单:采购单和子订单:在设计这个供应链系统时,我们需要满足以下两个需求:根据商品的型号/分类/生成年份/编码等查找订单;根据商品的型号/分类/生成年份/编码等查找采购......
  • 面试官:ConcurrentHashMap 是如何保证线程安全的
    1、前言阅读此篇文章,你需要有以下知识基础Java内存模型,可见性问题CASHashMap底层原理我们知道,在日常开发中使用的HashMap是线程不安全的,而线程安全类HashTable只是简单的在方法上加锁实现线程安全,效率低下,所以在线程安全的环境下我们通常会使用ConcurrentHashMap,但是又为何需要学习......
  • Spring Boot 监听 Redis Key 失效事件实现定时任务
    1、业务场景我们以订单功能为例说明下:生成订单后一段时间不支付订单会自动关闭。最简单的想法是设置定时任务轮询,但是每个订单的创建时间不一样,定时任务的规则无法设定,如果将定时任务执行的间隔设置的过短,太影响效率。还有一种想法,在用户进入订单界面的时候,判断时间执行相关操作。......
  • 第四节:Redis数据持久化机制(备份恢复)、缓存淘汰策略、主从同步原理、常见规范与优化
    一.数据持久化 1. 含义Redis提供了RDB和AOF两种持久化方式,默认开启的是RDB,如果需要AOF,需要手动修改配置文件进行开启。RDB:是一种对Redis存在内存中的数据周期性的持久化机制,将内存中的数据以快照的形式硬盘,实质上是fork了一个子进程在执行数据存储,采用的是二进制压......
  • 记一次Redis Cluster Pipeline导致的死锁问题
    作者:vivo互联网服务器团队-LiGang本文介绍了一次排查Dubbo线程池耗尽问题的过程。通过查看Dubbo线程状态、分析Jedis连接池获取连接的源码、排查死锁条件等方面,最终确认是因为使用了clusterpipeline模式且没有设置超时时间导致死锁问题。一、背景介绍RedisPipeline是一......
  • 安装redis
    1、下载redis下载地址:https://github.com/redis/redis/releases1、tar-zvxfredis-7.2.0.tar.gz2、cdredis-7.2.03、make4、makeinstallPREFIX=/usr/local/redis2、设置redis1、cpredis.conf/etc/redis.conf2、vim/etc/redis.conf#设置远程访问#bind127.0.......
  • PHP 操作redis 详细讲解转的
    phpredis是redis的php的一个扩展,效率是相当高有链表排序功能,对创建内存级的模块业务关系很有用;以下是redis官方提供的命令使用技巧:https://www.clw9335.com/gl/719374.html下载地址如下:https://github.com/owlient/phpredis(支持redis2.0.4)Redis::__construct构造函数$redi......
  • Redis学习--------分片集群、散列插槽、集群伸缩、故障转移
    Redis学习--------分片集群、散列插槽、集群伸缩、故障转移https://blog.csdn.net/qq_43719634/article/details/124911627Redis集群添加新节点(水平扩展)、删除其中一个节点https://blog.csdn.net/qq_33417321/article/details/119518848 ......