Redis分布式锁--面试题

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模式来保证强一致性