分布式锁之Zookeeper

本文引用地址
正常线程进程同步的机制有哪些？
·互斥：互斥的机制，保证同一时间只有一个线程可以操作共享资源 synchronized，Lock等。
·临界值：让多线程串行话去访问资源
事件通知：通过事件的通知去保证大家都有序访问共享资源
·信号量：多个任务同时访问，同时限制数量，比如发令枪CDL，Semaphore等
那分布式锁你了解过有哪些么？
分布式锁实现主要以Zookeeper（以下简称zk）、Redis、MySQL这三种为主。那先跟我聊一下zk吧，
你能说一下他常见的使用场景么？
他主要的应用场景有以下几个：
·服务注册与订阅（共用节点）
·分布式通知（监听znode）
·服务命名（znode特性）
·数据订阅、发布（watcher）
·分布式锁（临时节点）
zk是啥？*
他是个数据库，文件存储系统，并且有监听通知机制（观察者模式）
·存文件系统，他存了什么？
节点zk的节点类型有4大类
·持久化节点（zk断开节点还在）
·持久化顺序编号目录节点
·临时目录节点（客户端断开后节点就删除了）
·临时目录编号目录节点节点名称都是唯一的。
create /test laogong // 创建永久节点
create -e /test laogong // 创建临时节点
临时节点就创建成功了，如果我断开这次链接，这个节点自然就消失了。
create -s /test // 创建顺序节点
create -e -s /test // 创建临时顺序节点
zk就是基于节点去实现各种分布式锁的。
就拿开头的场景来说，zk应该怎么去保证分布式情况下的线程安全呢？并发竞争他是怎么控制的呢？为了模拟并发竞争这样一个情况，我写了点伪代码，大家可以先看看
我定义了一个库存inventory值为1，还用到了一个CountDownLatch发令枪，等10个线程都就绪了一起去扣减库存。是不是就像10台机器一起去拿到库存，然后扣减库存了？所有机器一起去拿，发现都是1，那大家都认为是自己抢到了，都做了减一的操作，但是等所有人都执行完，再去set值的时候，发现其实已经超卖了，我打印出来给大家看看。

是吧，这还不是超卖一个两个的问题，超卖7个都有，代码里面明明判断了库存大于0才去减的，怎么回事开头我说明了。那怎么解决这个问题？sync，lock也只能保证你当前机器线程安全，这样分布式访问还是有问题。上面跟大家提到的zk的节点就可以解决这个问题。
zk节点有个唯一的特性，就是我们创建过这个节点了，你再创建zk是会报错的，那我们就利用一下他的唯一性去实现一下。怎么实现呢？上面不是10个线程嘛？我们全部去创建，创建成功的第一个返回true他就可以继续下面的扣减库存操作，后续的节点访问就会全部报错，扣减失败，我们把它们丢一个队列去排队。那怎么释放锁呢？删除节点咯，删了再通知其他的人过来加锁，依次类推。我们实现一下，zk加锁的场景。
是不是，只有第一个线程能扣减成功，其他的都失败了。但是你发现问题没有，你加了锁了，你得释放啊，你不释放后面的报错了就不重试了。那简单，删除锁就释放掉了，Lock在finally里面unLock，现在我们在finally删除节点。加锁我们知道创建节点就够了，但是你得实现一个阻塞的效果呀，那咋搞？死循环，递归不断去尝试，直到成功，一个伪装的阻塞效果。怎么知道前面的老哥删除节点了嗯？
监听节点的删除事件

但是你发现你这样做的问题没？
是的，会出现死锁。第一个仔加锁成功了，在执行代码的时候，机器宕机了，那节点是不是就不能删除了？创建临时节点就好了，客户端连接一断开，别的就可以监听到节点的变化了。
嗯还不错，那你发现还有别的问题没？好像这种监听机制也不好。怎么个不好呢？你们可以看到，监听，是所有服务都去监听一个节点的，节点的释放也会通知所有的服务器，如果是900个服务器呢？这对服务器是很大的一个挑战，一个释放的消息，就好像一个牧羊犬进入了羊群，大家都四散而开，随时可能干掉机器，会占用服务资源，网络带宽等等。这就是羊群效应。那怎么解决这个问题？
好的，临时顺序节点，可以顺利解决这个问题。
怎么实现老公你先别往下看，先自己想想。之前说了全部监听一个节点问题很大，那我们就监听我们的前一个节点，因为是顺序的，很容易找到自己的前后。
和之前监听一个永久节点的区别就在于，这里每个节点只监听了自己的前一个节点，释放当然也是一个个释放下去，就不会出现羊群效应了。以上所有代码我都会开源到我的https://github.com/AobingJava/Thanos其实上面的还有瑕疵，大家可以去拉下来改一下提交pr，我会看合适的会通过的。
你说了这么多，挺不错的，你能说说ZK在分布式锁中实践的一些缺点么？
Zk性能上可能并没有缓存服务那么高。因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。
ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同步到所有的Follower机器上。（这里涉及zk集群的知识，我就不展开了，以后zk章节跟老公们细聊）
使用Zookeeper也有可能带来并发问题，只是并不常见而已。由于网络抖动，客户端可ZK集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。就可能产生并发问题了，这个问题不常见是因为zk有重试机制，一旦zk集群检测不到客户端的心跳，就会重试，Curator客户端支持多种重试策略。多次重试之后还不行的话才会删除临时节点。