锁
同时满足以下条件则必须上锁:1,有共享资源 ;2,多任务;3,共享资源在多任务下互斥
分布式锁
为什么需要
- 一般的锁:同一个jvm,不同的线程(以线程多任务),可以使用java自带的锁
- 分布式锁:对集群中 不同的jvm(以jvm进程多任务),jvm自带的锁锁不到另外的jvm
Redis实现分布式锁
SetNX [set if not exists] :
set的key,如果redis中不存在这个key,则set成功并返回true,如果redis中已存在这个key,则不做任何操作,返回false。
实现思路:将资源(请求参数如商品ID) 作为key使用 SetNX存到redis,返回值为true时可以继续执行业务代码(代表抢到锁),为false时代表当前资源被占用,需要在客户端自旋等待锁释放(需要重新抢锁时),或直接结束(抢锁失败不需重新抢锁);执行完业务代码,删掉这个key(释放锁)。
Redis 分布式锁有哪些问题
-
没有释放锁
应用已经异常宕机,但redis未感知,key一致存在,则后续任务阻塞。 expire 时设置过期时间。
-
不是原子操作
setnx不支持设置超时参数,需要额外的指令expire(key, time),而setnx和expire的非原子性。[ɪkˈspaɪər]
-
提前释放了锁
expire设置的过期时间太短,而提前释放了锁,导致其他任务抢到锁,造成并发,加锁失败。(Redission 会自动续期:加锁时,先设置一个预估的过期时间,然后开启一个守护线程,定时去检测这个锁的失效时间,如果锁快要过期了,操作共享资源还未完成,那么就自动对锁进行续期,这个守护线程一般叫它看门狗线程)
-
释放了别人的锁
是上一个问题的延续问题。A线程持有锁,但是因为任务运行耗时较长,提前释放了锁。B线程获取到锁,B还没执行完,此时A又执行完了,执行锁被释放,而释放掉了B。
– 解决办法: 将当前线程生成的UUID作为value 存到此key 中,在删除锁的时候, 判断是当前的UUID才删除。
生成编码规则中使用 redission 的原理就是上述。 -
…
-
丢失锁(redis集群时)
以上都是redis单点部署时会有问题。Redis集群自身只保证最终一致性,副本之间的数据复制是异步执行,主从切换之后可能存在部分数据没有复制过去,而加锁失败。
需要特别注意的是,RedissonLock 同样没有解决 节点挂掉的时候,存在丢失锁的风险的问题。而现实情况是有一些场景无法容忍的,所以 Redisson 提供了实现了redlock算法的RedissonRedLock,真正解决了单点失败的问题,代价是需要额外的为 RedissonRedLock 搭建Redis环境。
所以,如果业务场景可以容忍这种小概率的错误,则推荐使用 RedissonLock; 如果无法容忍,则推荐使用 RedissonRedLock,或者改用zk。
问题和解决办法何以参考:https://blog.csdn.net/fuzhongmin05/article/details/119251590
Zookeeper实现分布式锁
利用临时顺序节点znode,创建节点的客户端与zookeeper断开连接后,临时节点会被删除(创建锁和释放锁)。和节点监听。
实现思路:
-
获取锁
首先,在Zookeeper当中创建一个持久节点ParentLock。
当第一个客户端想要获得锁时,需要在ParentLock这个节点下面创建一个临时顺序节点 Lock。
Client1查找ParentLock下面所有的临时顺序节点并排序,判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是,则成功获得锁。如果再有一个客户端 Client2 前来获取锁,则在ParentLock下载再创建一个临时顺序节点Lock2,Client2查找ParentLock下面所有的临时顺序节点并排序,判断自己所创建的节点Lock2是不是顺序最靠前的一个。如果不是,则向它前一个节点Lock1注册Watcher,监听Lock1节点是否存在。这意味着Client2抢锁失败,进入了等待状态。以此类推Lock3监听Lock2,形成了一个等待队列。
-
释放锁
Client1任务完成时,会调用删除节点Lock1的指令。或Client1宕机时则会断开与Zookeeper服务端的链接。根据临时节点的特性,相关联的节点Lock1会随之自动删除。
当Lock1节点被删除,Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点,确认自己创建的节点Lock2是不是目前最小的节点。如果是最小,则Client2顺理成章获得了锁。
总结:
每一个想要获取锁的客户端,都需要在ParentLock这个节点下面创建一个临时顺序节点,再判断自己创建的节点是不是最靠前的一个(所有客户端中同一时间只会有一个最前),如果是,则当前客户端抢到锁;否则直接返回(抢锁失败后不需继续),或向前一个节点注册Watcher,当前一个节点释放时,能够感知到,并获取锁。
两种方式实现分布式锁的优劣
分布式锁 优点 缺点
--------------------------------------------------------------------------------
Zookeeper 1.有封装好的框架,容易实现。 1. 添加和删除节点性能较低(添加节点是写文件)
2.有等待锁的队列,大大提升抢锁效率。
--------------------------------------------------------------------------------
Redis 2. Set和Del指令性能较高(内存数据操作) 1.实现复杂,需要自己考虑超时,原子性,误删等情形。
2.没有等待锁的队列,只能在客户端自旋,效率低下。