1. Redis分布式锁原理
1.1. Redisson
现在最流行的redis分布式锁就是Redisson了,来看看它的底层原理就了解redis是如何使用分布式锁的了
![41fe97c5a415163f581da71dcf846af4.png](https://i-blog.csdnimg.cn/blog_migrate/9210cce379c582b9371ba405e92559c2.jpeg)
1.2. 原理分析
分布式锁要解决的是分布式环境下,并行相同代码的加锁功能;了解过redis分布式锁的人肯定知道,一开始redis作为分布式锁用的是setnx,再这基础上设置个定时过期时间,但这种方式有什么问题呢?
实际上看懂上图的人也就明白了那有什么问题,首先是原子性问题,setnx+过期时间这两个操作必须是原子性的,所以这可以用lua脚本解决
再然后是释放锁的时机该如何定?
- 不管我们定多少过期时间,都不能保证,在这段时间内锁住的代码执行完成了,所以这个时间定多少都不好;
- 如果不定时间,当执行完成后释放锁,问题就是如果执行到一半机器宕机,那这把锁就永远放不掉了
那Redisson是如何解决上述问题的呢?
- 它对代码进行了精简的封装,我们的使用非常简单,甚至我们不用主动设置过期时间
- 它设计了个watch dog看门狗,每隔10秒会检查一下是否还持有锁,若持有锁,就给他更新过期时间30秒;通过这样的设计,可以让他在没有释放锁之前一直持有锁,哪怕宕机了,也能自动释放锁
- 而不能获得锁的客户端则是不断循环尝试加锁
- 通过记录锁的客户端id,可以把它设计成可重入锁
![3e6e54a367c039197c7965bc07696fb4.png](https://i-blog.csdnimg.cn/blog_migrate/c4a68daa1ad90148a93a063931157d86.jpeg)
1.3. 存在问题
redis作为分布式锁再大多数情况下是没问题的,但是我们知道CAP原理,一致性,可用性,分区容错性
在redis分布式架构中,我们其实保证的是AP模型,也就是尽可能的保证了redis的可用性,这在一般系统中当然是没问题的,哪怕有时候一致性有点问题(实际读到的数据不正确,或已经写入没读到)毕竟是作为缓存的存在,一定延迟可以接受,没读到可以再读数据库,这是没问题的。
但在分布式锁中,一旦出现该读到没读到,那就是重复锁的问题了,相当于分布式锁没起到作用。
这种情况发生在什么时候呢?redis集群主节点再获取锁后,没来得及复制数据给从节点,此时宕机了,从节点接替主节点进行读写,此时新的主节点没有持有该锁,那么其他想要获取该锁的服务也可以获取到该锁,导致了重复锁的问题。
一般来讲这种情况发生的概率是很小的,看你系统的规模而定,我觉得像阿里这种规模就应该不会用redis来作为分布式锁了
CP模型的分布式锁可以用zookeeper,可能性能略低于redis,但能保证安全,可以提供顺序锁等额外功能
原文:https://www.cnblogs.com/sky-chen/p/11362935.html