如何进行Zookeeper 分布式锁的分析

这期内容当中小编将会给大家带来有关如何进行Zookeeper 分布式锁的分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

我们借助 Zookeeper 实现一个不可重入的分布式锁！

分布式锁对 Java 的 JUC 包来说就显得无能为力了。所以我们要借助 Zookeeper 的最小版本，Redis 的 set 函数，数据库锁来实现分布式锁。

我们知道在 Zookeeper 中是使用文件目录的格式存放节点内容，其中节点类型分为：

• 持久节点（PERSISTENT ）：节点创建后，一直存在，直到主动删除了该节点。

  
  

• 临时节点（EPHEMERAL）：生命周期和客户端会话绑定，一旦客户端会话失效，这个节点就会自动删除。

  
  

• 序列节点（SEQUENTIAL ）：多个线程创建同一个顺序节点时候，每个线程会得到一个带有编号的节点，节点编号是递增不重复的，如下图：

如上图，三个线程分别创建路径为 /root/node 的节点，可知在 zk 服务器端会在 root 下存在三个 node 节点，并且线程编号是唯一递增。

具体在节点创建过程中，可以混合使用，比如临时顺序节点（EPHEMERAL_SEQUENTIAL），本文我们就使用临时顺序节点来实现分布式锁。

创建临时顺序节点,比如 /root/node，假设返回结果为 nodeId。

获取 /root 下所有孩子节点，用自己创建的 nodeId 的序号与所有子节点比较，看看自己是不是编号最小的。如果是最小的则就相当于获取到了锁，如果自己不是最小的，则从所有子节点里面获取比自己次小的一个节点，然后设置监听该节点的事件，然后挂起当前线程。

当最小编号的线程获取锁，处理完业务后删除自己对应的 nodeId，删除后会激活比自己大一号的节点的线程从阻塞变为运行态，被激活的线程应该就是当前 node 序列号最小的了，然后就会获取到锁。

明白原理后，代码写起来就非常的简单了。

ZookeeperDistributedLock 的构造函数创建 zkclient，并且注册了监听事件，然后调用 connectedSignal.await() 挂起当前线程。当 zkclient 链接到服务器后，会给监听器发送 SyncConnected 事件，监听器判断当前链接已经建立了，则调用 connectedSignal.countDown(); 激活当前线程，然后创建 root 节点。

获取锁的方法 lock，内部首先创建 /root/lockName 的顺序临时节点，然后获取 /root 下所有的孩子节点，并对子节点进行排序，然后判断自己是不是最小的编号，如果是直接返回 true 标示获取锁成功。否者看比自己小一个号的节点是否存在，存在则注册该节点的事件，然后挂起当前线程，等待比自己小一个数的节点释放锁后发送节点删除事件，事件里面激活当前线程。

释放锁的方法 unlock 比较简单，就是简单的删除获取锁时候创建的节点。

Zookeeper 非常的强大，当你真正的了解后，你会发现它能做很多事情。

光分布锁方面，它都能帮助我们实现好几种，如下面我列举的这些：

• 可重入锁Shared Reentrant Lock

  
  

• 不可重入锁Shared Lock

  
  

• 可重入读写锁Shared Reentrant Read Write Lock

  
  

• 信号量Shared Semaphore

  
  

• 多锁对象 Multi Shared Lock

上述就是小编为大家分享的如何进行Zookeeper 分布式锁的分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。