Redis分布式锁--面试题

发布时间:2024年01月18日
Redis的分布式锁

在多台服务时不能使用synchronized,原因是多台服务之间会失效,需要用到Redis的分布式锁。

可以利用Redis的setnx命令来实现分布式的加锁,但无法保证原子性,是因为要在setnx之后在加上锁的过期时间,这是俩条命令,需要放到一条命令中来保证原子性。

Redis本身没有事务,但可以通过一些命令来完成类似于事务的方式,但无法回滚。

推荐使用set lock value NX EX 10。解读:lock锁的名称,也就是key,value:lock的值(也就是资源),NX标识表示互斥,EX后加过期时间。

加过期时间是为了防止死锁的出现。例如出现:业务超时,服务宕机等情况。

在释放锁是直接DEL key(锁的名字)即可。

Redis的分布式锁如何合理的控制有效时长(问的是redisson的分布式锁)

问题解析:当给分布式锁设置了一个过期时间,但业务执行时间比较长,锁在业务执行时释放了,就无法保证业务执行的原子性了。锁设置的过期时间不能太长也不能太短。

解决方案:

  • 根据业务的执行时间进行预估:不推荐
  • 给锁续期:实现原理:给锁设置过期时间时,在开一个线程来监控业务的执行,如果业务执行时间长就增加锁的时长。使用redisson实现。.getLock("锁")获取锁.tryLock(获取锁的最大等待时间,单位)尝试获取锁.unlock()释放锁实现,可以说对Redis的分布式锁做了优化
Redisson实现分布锁的流程

redisClient.getLock("锁").tryLock(重试时间,时间单位)获取锁

Redisson的加锁、设置过期时间等操作基于lua脚本完成(保证多条Redis命令的原子性)

  • Redisson实现分布锁的流程
    • 首先线程会先尝试获取锁
    • 尝试加锁成功后,redisson会再开一个Watch dog(看门狗)线程来监控持有锁的线程。
    • 看门狗线程会每隔releaseTime(默认30秒)/3的时间做一次续期,增加线程持有锁的时间
    • 同时线程操作redis,完成之后手动释放锁,redisson自动通知Watch dog撤销线程的监控。
  • 当有新线程来获取锁时,会先尝试加锁,加锁失败会进行重试,重试的时间可以在代码中通过.tryLock设置重试时间,它是可以在高并发的情况,提高分布式锁的使用性能
Redisson实现的分布式锁是否可以重入

重入:指的是线程不一样,锁一样

redis实现的分布式锁不可重入

redisson实现的分布式锁可以重入,它是根据线程的id和锁名称一起判断的。

java中synchronized、ReentrantLock关键字也是重入的

使用场景:业务负责,锁的粒度小的时候可以使用锁的重入,避免多个锁之间产生死锁的问题。

redisson使用hash结构记录线程id和重入次数。key是锁名称,value是线程id和重入次数。必须保证是同一个线程才会出现锁的重入,不是同一个线程会互斥。

Redisson的分布式锁可以保证主从数据的一致吗?

解析:redisson的分布式锁在redis宕机之后,哨兵会重新选举一个主节点,此时一个服务正在对原主节点操作,原主节宕机后没有同步数据,又来一个服务对新主节点操作,它是可以获取到锁的,是因为数据没有同步过来,这时两个服务同时持有一把锁,就会产生脏数据。(redis的整体思想是AP高可用的)

不能保证,但可以使用redisson的红锁(RedLock)来解决,不在一个实例上加锁,在多个实例上加锁(加锁的实例数:redis实例数/2+1),但它的性能低,如果非要保证数据的强一致性,可以在采用cp思想的zookeeper或者Seate的的XA模式来保证强一致性

文章来源:https://blog.csdn.net/weixin_48540423/article/details/135661003
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。