Redis/Zookeeper分布式锁

昱东i

已于 2022-10-25 21:35:32 修改

阅读量551

点赞数

分类专栏： Java 文章标签： redis 分布式 zookeeper

于 2022-05-16 12:47:11 首次发布

本文链接：https://blog.csdn.net/qq_45494908/article/details/124797416

版权

Java 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

锁

同时满足以下条件则必须上锁：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.没有等待锁的队列，只能在客户端自旋，效率低下。