redis分布式锁可靠吗

写在前面的话

2020年2月22日来杭，
杭州天气不错，
晴空万里，气温回暖，
疫情彷佛散去，
而我开始了既定的跳槽，
投简历，刷面试片刻未敢停留。

一周下来也差不多面了10来家公司，
反馈还行，
但是并没有想象中的那么好，
总体来看杭州互联网既没有那么好，
也没有想象的那么槽。

所以小伙伴们适度焦虑就OK，
重要的还是提升自己的硬实力。
下面来讲几个面试碰到的有意思的问题吧。

如何确定分布式锁的释放时间？

描述：就是你在使用分布式锁对代码加一个锁，会不会业务没有执行完，锁释放了？
我脑子一转这种情况肯定不能让他发生，不然不是并发了吗。

此时你需要想一下分布式锁的实现？？？？
setnx??? set?
如果你说setnx我估计是要歇菜的，因为你刚好掉进面试官的一个坑里，我们来看下setnx命令

没有过期时间？？？没有过期时间意味着锁要我们自己手动释放，看下伪代码

if(setnx('key',1)){
	// 1.
	try{
		// 2.业务逻辑
	}catch(Exception e){
		// 3.异常处理
	}finally{
		// 4.
		del 'key'
	}
}

假设在上述代码的1或者4处出现异常，或者说是出现error，比如内存溢出，jvm直接不可用，那么这个锁是不是就释放不掉了？？别的线程就无法访问这段代码了，这就是死锁的现象。基于这个问题，我们用什么方式来解决呢？首先系统层面是无法解决的，但是我们可以用reids的过期策略来解决。比如说我们用别的redis的set命令

SET key value [EX seconds] [PX milliseconds] [NX|XX]
将字符串值 value 关联到 key 。
如果 key 已经持有其他值， SET 就覆写旧值，无视类型。
对于某个原本带有生存时间（TTL）的键来说， 当 SET 命令成功在这个键上执行时， 这个键原有的 TTL 将被清除。
可选参数
从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改：
EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
XX ：只在键已经存在时，才对键进行设置操作。

分析上面的命令发现，其实并没有合适的命令，具有过期时间的命令其实可以帮助我们解决系统异常出现的无法释放锁的问题，但是这些命令其实是可以重复set的，所以可以认为没有排他性，有的同学可能会说在set前先get一下，但是如果get出现并发其实还是可以有多个线程可以获得到锁的。

当然我们使用的分布式锁还有通过redisson实现的，这个是有过期时间的，那么这个过期时间是否导致我们的业务没走完，锁释放了？同样不存在的，redisson在获取锁之后，会维护一个看门狗，当锁即将过期还没有释放时，看门狗会给过期时间进行续航。

结论：无论是使用setnx命令还是redisson都无法解决这种极端情况的死锁现象。但是这种场景是极端情况发生的，而且一旦发生，我们的应用都不可用了，死锁的问题就相对较轻了，我们应该抓紧恢复我们的服务，死锁手动释放下就好了。

分布式锁一定安全吗？？？

答：不一定。我们来看一个简单的主从获取锁的流程

我们考虑一种情况，在应用程序获取锁之后，还没来得及复制到从节点时，主节点下线了，这时会进行故障转移，主从节点的角色会调换，那么此时新的主节点肯定是还没有锁的key的，那么客户端的请求过来时肯定会再次获得锁成功。

上面的问题客观存在，不了解故障转移的看下我这篇文章redis哨兵

这个问题同样无法解决，但是这种情况发生的概率极低，他要满足两种情况

1. 获取锁成功后redis主节点不可用
2. 故障转移后的主节点没有完全复制完数据

其实这种情况的概率是极低的，首先故障转移之前会做客观下线与主管下线判断，还会进行领头哨兵的选举，这个过程给了一定的主从复制的时间，其次故障转移挑选出的新的主节点肯定是复制偏移量最大的，这也降低了新的主节点丢失数据的风险。
最后不懂主从复制的可以看下我的这篇文章redis主从复制

扫码关注