面试官:你真的了解Redis分布式锁吗? (3)

2、先设定key的有效时长(TTL),超出这个时间就会自动释放,然后client(客户端)尝试使用相同的key和value对所有redis实例进行设置,每次链接redis实例时设置一个比TTL短很多的超时时间,这是为了不要过长时间等待已经关闭的redis服务。并且试着获取下一个redis实例。

比如:TTL(也就是过期时间)为5s,那获取锁的超时时间就可以设置成50ms,所以如果50ms内无法获取锁,就放弃获取这个锁,从而尝试获取下个锁;

3、client通过获取所有能获取的锁后的时间减去第一步的时间,还有redis服务器的时钟漂移误差,然后这个时间差要小于TTL时间并且成功设置锁的实例数>= N/2 + 1(N为Redis实例的数量),那么加锁成功

比如TTL是5s,连接redis获取所有锁用了2s,然后再减去时钟漂移(假设误差是1s左右),那么锁的真正有效时长就只有2s了;

4、如果客户端由于某些原因获取锁失败,便会开始解锁所有redis实例。

根据这样的算法,我们假设有5个Redis实例的话,那么client只要获取其中3台以上的锁就算是成功了,用流程图演示大概就像这样:

面试官:你真的了解Redis分布式锁吗?

好了,算法也介绍完了,从设计上看,毫无疑问,RedLock算法的思想主要是为了有效防止Redis单点故障的问题,而且在设计TTL的时候也考虑到了服务器时钟漂移的误差,让分布式锁的安全性提高了不少。

但事实真的是这样吗?反正我个人的话感觉效果一般般,

首先第一点,我们可以看到,在RedLock算法中,锁的有效时间会减去连接Redis实例的时长,如果这个过程因为网络问题导致耗时太长的话,那么最终留给锁的有效时长就会大大减少,客户端访问共享资源的时间很短,很可能程序处理的过程中锁就到期了。而且,锁的有效时间还需要减去服务器的时钟漂移,但是应该减多少合适呢,要是这个值设置不好,很容易出现问题。

然后第二点,这样的算法虽然考虑到用多节点来防止Redis单点故障的问题,但但如果有节点发生崩溃重启的话,还是有可能出现多个客户端同时获取锁的情况。

假设一共有5个Redis节点:A、B、C、D、E,客户端1和2分别加锁

客户端1成功锁住了A,B,C,获取锁成功(但D和E没有锁住)。

节点C的master挂了,然后锁还没同步到slave,slave升级为master后丢失了客户端1加的锁。

客户端2这个时候获取锁,锁住了C,D,E,获取锁成功。

这样,客户端1和客户端2就同时拿到了锁,程序安全的隐患依然存在。除此之外,如果这些节点里面某个节点发生了时间漂移的话,也有可能导致锁的安全问题。

所以说,虽然通过多实例的部署提高了可用性和可靠性,但RedLock并没有完全解决Redis单点故障存在的隐患,也没有解决时钟漂移、客户端长时间阻塞而导致的锁超时失效问题。

从这一点上看,RedLock算法也并没有保证锁的安全性。

结论

有人可能要进一步问了,那该怎么做才能保证锁的绝对安全呢?

对此我只能说,鱼和熊掌不可兼得,我们之所以用Redis作为分布式锁的工具,很大程度上是因为Redis本身效率高且单进程的特点,即使在高并发的情况下也能很好的保证性能,但很多时候,性能和安全不能完全兼顾,如果你一定要保证锁的安全性的话,可以用其他的中间件如db、zookeeper来做控制,这些工具能很好的保证锁的安全,但性能方面只能说是差强人意,否则大家早就用上了。

一般来说,用Redis控制共享资源并且还要求数据安全要求较高的话,最终的保底方案是对业务数据做幂等控制,这样一来,即使出现多个客户端获得锁的情况也不会影响数据的一致性。当然,也不是所有的场景都适合这么做,具体怎么取舍就需要各位看官自己处理啦,毕竟,没有完美的技术,只有适合的才是最好的。

如果您觉得文章有用的话,欢迎点个赞或转发支持一下,这将是对我创作的最好鼓励!

作者:鄙人薛某,一个不拘于技术的互联网人,喜欢用通俗易懂的语言来解构后端技术的知识点,想看更多精彩文章的可以关注我的公众号,微信搜索【鄙人薛某】即可关注

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpdjsx.html