前言
我们之前讲了很多锁的只用，比如synchonrized、ReentrantLock、AQS等等。
这些都是单体应用下锁的一些使用。众所周知，我们现在的应用都是分布式的。所以上面那些锁已经无法满足我们了。
我们需要用到分布式锁，分布式锁一般有三种实现方式，如：MySQL数据库、Redis、zookeeper。
其中zookeeper和Redis的实现方式普通被各大公司使用，他们各自也都有优缺点。我们今天主要讲一下zookeeper分布式锁的实现。Redis分布式锁我们之后也会讲到。
zookeeper简介
Zookeeper是一个开源的分布式协调服务，是一个典型的分布式数据一致性解决方案。
分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。
ZK实现分布式锁的两个重要概念
ZNode节点
ZK的存储结构类似于Windows的文件系统。区别在于window他的目录是不能存储数据的，只有文件才能存储数据。
但是ZK的所有层级目录，都成为ZNode，他们都是一样的，没有目录和文件这种说法。只有父节点和子节点的概念。
无论是哪个层级的ZNode节点，都是可以存储数据的。
下面是zookeeper客户端连接工具截图：
ZNode节点种类
临时节点客户端与zookeeper断开连接后，该节点会自动删除临时有序节点客户端与zookeeper断开连接后，该节点会自动删除，但是这些节点都是有序排列的。持久节点客户端与zookeeper断开连接后，该节点依然存在持久节点客户端与zookeeper断开连接后，该节点依然存在，但是这些节点都是有序排列的。watch监听机制
主要是监听以下节点变化信息。
错误的实现分布式锁方式
锁原理
多个客户端同时去创建同一个临时节点，哪个客户端第一个创建成功，就成功的获取锁，其他客户端获取失败。
就像双十一，十万人同时秒杀一个商品，谁手速快谁就能秒杀到。
获取锁的流程
这里我们使用的是临时节点。
四个客户端同时创建一个临时节点。谁第一个创建成功临时节点，就代表持有了这个锁（这里临时节点就代表锁）。其他红色的客户端判断已经有人创建成功了，就开始监听这个临时节点的变化。
释放锁的流程
红色线的客户端执行任务完毕，与zookeeper断开了连接。这时候临时节点会自动被删除掉，因为他是临时的。其他绿色线的客户端watch监听到临时节点删除了，就会一拥而上去创建临时节点（也就是创建锁）
存在的问题分析
当临时节点被删除的时候，其余3个客户端一拥而上抢着创建节点。3个节点比较少，性能上看不出什么问题。
那如果是一千个客户端在监听节点呢？一旦节点被删除了，会唤醒一千个客户端，一千个客户端同时来创建节点。
但是只有一个客户端能创建成功，却要让一千个客户端来竞争。
对zookeeper的压力会很大，同时浪费这些客户端的线程资源，其中有个客户端是白跑一趟的。
这就叫做惊群现象，也叫羊群现象。
一个节点释放删除了，却要惊动一千个客户端，这种做法太傻了吧。
正确的实现分布式锁方式
这里用的是顺序临时节点。
锁原理
多个客户端来竞争锁，各自创建自己的节点，按照顺序创建，谁排在第一个，谁就成功的获取了锁。
就像排队买东西一样，谁排在第一个，谁就先买。
创建锁的过程
A、B、C、D四个客户端来抢锁A先来了，他创建了的临时顺序节点，他发现自己是最小的节点，那么就成功的获取到了锁然后B来获取锁，他按照顺序创建了的临时顺序节点，发现前面有一个比他小的节点，那么就获取锁失败。他开始监听A客户端，看他什么时候能释放锁同理C和D。
释放锁的过程
A客户端执行完任务后，断开了和zookeeper的会话，这时候临时顺序节点自动删除了，也就释放了锁B客户端一直在虎视眈眈的watch监听着A，发现他释放了锁，立马就判断自己是不是最小的节点，如果是就获取锁成功C监听着B，D监听着C。合理性分析
A释放锁会唤醒B，B获取到锁，对C和D是没有影响的，因为B的节点并没有发生变化。
同时B释放锁，唤醒C，C获取锁，对D是没有影响的，因为C的节点没有变化。
同理D。。。。
释放锁的操作，只会唤醒下一个客户端，不会唤醒所有的客户端。所以这种方案不存在惊群现象。
ps：创建临时节点=创建锁，删除临时节点=释放锁。
代码实现
我们这里直接用封装好的工具类，因为如果你自己写的话，如果测试不到位，一旦线上出现问题，那就是大问题。
这里我们用curator这个工具类，他这里把分布式锁已经都给我们实现好了，我们使用起来就像ReentrantLock这些锁一样，非常简单。
如果大家有兴趣，可以去阅读一下curator的源码。
pom文件配置
dependencygroupIdorg.apache.curator/groupIdartifactIdcurator-recipes/artifactIdversion4.0.0/versionexclusionsexclusiongroupIdorg.apache.zookeeper/groupIdartifactIdzookeeper/artifactId/exclusion/exclusions/dependencydependencygroupIdorg.apache.zookeeper/groupIdartifactIdzookeeper/artifactIdversion3.4.10/version/dependencyjava代码
importorg.apache.curator.framework.CuratorFramework;importorg.apache.curator.framework.CuratorFrameworkFactory;importorg.apache.curator.framework.recipes.locks.InterProcessMutex;importorg.apache.curator.retry.RetryNTimes;importjava.util.concurrent.TimeUnit;/***curator分布式锁测试*/publicclassCuratorDistrLockTestimplementsRunnable{//zookeeper的地址privatestaticfinalStringZK_ADDRESS=.0.0.1:;privatestaticfinalStringZK_LOCK_PATH=/zkLock;staticCuratorFrameworkclient=null;static{//连接ZK，如果连接失败，设置每毫秒重试一次，最多重试10次client=CuratorFrameworkFactory.newClient(ZK_ADDRESS,newRetryNTimes(10,));client.start();}privatestaticvoidcuratorLockTest(){InterProcessMutexlock=newInterProcessMutex(client,ZK_LOCK_PATH);try{if(lock.acquire(6*,TimeUnit.SECONDS)){System.out.println(======+Thread.currentThread().getName()+抢到了锁======);//执行业务逻辑Thread.sleep(1);System.out.println(Thread.currentThread().getName()+任务执行完毕);}}catch(Exceptione){System.out.println(业务异常);}finally{try{lock.release();}catch(Exceptione){System.out.println(锁释放异常);}}}publicstaticvoidmain(String[]args){//用两个线程，模拟两个客户端//每个线程创建各自的zookeeper连接对象newThread(newCuratorDistrLockTest()).start();newThread(newCuratorDistrLockTest()).start();}
Overridepublicvoidrun(){curatorLockTest();}}执行结果同时观察zookeeper客户端的变化，zkLock目录下出现了两个临时顺序节点。
程序结束后，我们在刷新zookeeper客户端，发现zkLock目录下的临时顺序节点已经被自动删除了。
总结
为什么不采用持久节点呢，因为持久节点必须要客户端手动删除，否则他会一直存在zookeeper中。
如果我们的客户端获取到了锁，还没释放锁就突然宕机了，那么这个锁会一直存在不被释放。导致其他客户端无法获取锁。
zookeeper实现的锁功能是比较健全的，但是性能上稍微差一些。比如zookeeper要维护集群自身信息的一致性，频繁创建和删除节点等原因。
如果仅仅是为了实现分布式锁而维护一套zookeeper集群，有点浪费了。
如果公司本来就有zookeeper集群，同时并发不是非常大的情况下，可以考虑zookeeper实现分布式锁。
Redis在分布式锁方面的性能要高于zookeeper，同时他也存在他的缺点，我们之后会分析。
给个[在看]，是对IT老哥最大的支持