背景

之前说到分布式锁的实现有三种
1、基于数据库实现的分布式锁
2、Redis分布式锁
3、Zookeeper分布式锁
前者redis分布式锁博客已具体介绍，此博客最终决定补齐关于Zookeeper分布式锁的实现原理。

简述

Zoopkeeper，它是一个为分布式的协调服务，基于CP，注重数据的一致性，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。
简单来说，zookeeper相当于文件系统+监听通知机制。

Zookeeper的四种类型节点

• PERSISTENT-持久化目录节点
  客户端与zookeeper断开连接后，该节点依旧存在

• PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
  客户端与zookeeper断开连接后，该节点依旧存在，并且Zookeeper给该节点名称进行顺序编号

• EPHEMERAL-临时目录节点
  客户端与zookeeper断开连接后，该节点被删除

• EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
  并且Zookeeper给临时目录节点进行顺序编号

zk的事件监听

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
zookeeper使用watcher机制实现数据的发布订阅功能，该机制在被订阅对象发生变化时会异步通知客户端，因此客户端不必再watcher注册后轮询堵塞，从而减轻客户端压力。

基于ZooKeeper实现分布式锁的步骤如下：
2.基于zookeeper ： 使用临时顺序节点+监听实现，线程进来都去创建临时顺序节点,第一个节点的创建线程获取到锁，后面的节点监听自己的上一个节点的删除事件，如果第一个节点被删除，释放锁第二个节点就成为第一个节点，获取到锁。

zookeeper分布式锁

针对zookeeper以上及节点和监听机制的特性，可以使用临时有序节点+监听机制来实现zookeeper分布式锁
实现原理：
1、一把分布式锁通常使用一个Znode节点（以/lock为例）表示，如果锁对应的Znode节点不存在，先创建Znode节点。代表分布式锁。
2，线程1获取锁时，在节点/lock下建一个临时有序子节点，第一个节点是当前序号最小的节点，表示获取到锁。
3、当线程2获取锁时，在节点/lock下创建一个临时有序节点，此时判断当前自己的节点序号是否最小，不是，表示拿不到锁，则需要监听上一个节点。
4、当获取到锁的节点线程1执行业务完毕后，释放锁，即删除该节点，表锁被释放。
5、此时第二个节点监听到第一个节点被删除，成为第一个锁，获取到锁
6、以上以此类推

因此，当线程创建的子节点是当前锁下子节点列表中序号最小的有一个时，表示获取到锁，否则监听上一个锁节点，直接上一个子节点被删除，成为第一个节点时获取到锁

以图为例：

图(1)线程1获取到锁，其他线程排队等待

图(2) 线程1执行完毕，删除当前节点，节点2监听到上一节点被删，获取锁执行

三种分布式锁优缺点

总结

根据应用场景选择
● 基于ZooKeeper的分布式锁，适用于高可靠（高可用）而并发量不是太大的场景。如果实际业务场景，更需要的是保证数据一致性，适用于CP型的zookeeper分布式锁。

● 基于Redis的分布式锁，适用于并发量很大、性能要求很高的。如果实际业务场景，更需要的是保证数据高可用性。适用于AP类型的redis分布式锁。

参考文档：https://blog.csdn.net/weixin_45125989/article/details/130493038
redis分布式锁：https://superteam.blog.csdn.net/article/details/132958060

author：yana