在面巨量引擎时，碰到了这道面试问题：怎样用 Zookeeper 完成分布式锁?
坚信绝大多数招聘面试全是怎么用 Redis 去完成分布式锁，用 Zookeeper 完成分布式锁相对来说碰到的偏少，近期在梳理以前的面经回答，因而刻意写一篇blog解释一下。
完成一把分布式锁一般有很多方式 ，较为普遍的有 redis 和 Zookeeper。坚信大伙儿对 redis 完成分布式锁早已十分掌握，今日详细介绍的是怎样根据 Zookeeper 去完成一把分布式锁。
最先 Zookeeper 为何能完成一把分布式锁呢?这是由于它有一个特点，便是好几个进程去 Zookeeper 里边去建立同一个连接点的情况下，总是有一个进程去实行取得成功。
照片
内部推荐
Zookeeper 的 ZNode 连接点
在掌握 Zookeeper 完成分布式锁以前，最先，大家必须掌握 Zookeeper 里边连接点有关的专业知识。
Zookeeper 里边的连接点能够分成两类，一种是临时性连接点，一种是持久化连接点。
临时性连接点，指的是连接点建立后，假如建立连接点的手机客户端和 Zookeeper 服务器端的对话无效(比如中断连接)，那麼连接点便会被删掉。
持久化连接点指的是连接点建立后，即便建立连接点的手机客户端和 Zookeeper 服务器端的对话无效(比如中断连接)，连接点也不会被删掉，仅有手机客户端积极进行删掉连接点的要求，连接点才会被删掉。
此外也有一种连接点称为井然有序连接点，这类连接点在建立的时候会有一个编号，这一编号是自增的。井然有序连接点既能够是井然有序临时性连接点，还可以是井然有序持久化连接点。
Zookeeper 中全部的数据信息全是根据连接点来储存的，它的文件目录构造如同一个文档树，如下图。
照片
Zookeeper构造
图上的 locks、register、data 这好多个文件目录自定建立的，各自用于储存不一样业务流程的数据信息，比如 locks 用于储放分布式锁有关的信息内容，register 用于储放认证中心有关的数据信息。
如今我们要获得一个分布式系统的所，那麼假定这一锁的 K 称为 K1，那麼如今有一个手机客户端 a，随后去 JK 里边去建立一个分布式系统的，所建立 K1 这一分布式锁，那麼他便会在 nex 这一文件目录下边建立一个称为 K1 的文件夹名称，称为 K1 的文档。如今我们要获得一个分布式系统的所，那麼假定这一锁的 K 称为 K1，那麼如今有一个手机客户端 a，随后去 JK 里边去建立一个分布式系统的，所建立 K1 这一分布式锁，那麼他便会在 nex 这一文件目录下边建立一个称为 K1 的文件夹名称，称为 K1 的文档。
怎样完成
选用 Zookeeper 完成分布式锁，有二种计划方案：1. 根据临时性连接点完成;2. 根据临时性次序连接点完成。下边及其详细介绍这类计划方案的完成基本原理。
最先，假定全部的分布式锁都储存在 locks 这一文件目录中。
计划方案一：根据临时性连接点完成(不强烈推荐)
假定现在有手机客户端 A、B、C 均来获得同一把分布式锁：Key1。
最先，手机客户端 A 来获得分布式锁 Key1，那麼它便会试着在 locks 这一文件目录下来建立一个称为 Key1 的 ZNode 连接点。假如这个时候 locks 文件目录里边沒有 Key1 这一 ZNode 连接点，那麼手机客户端 A 就能取得成功建立 Key1 连接点，这就表明手机客户端 A 取得成功获得到 Key1 这把锁锁。
照片
图1
另外，手机客户端 B 也来获得 Key1 这把锁。手机客户端 B 也必须去 locks 这一文件目录里边去建立 Key1 ZNode 连接点，这个时候，因为 Key1 这一 ZNode 连接点早已存有，因此手机客户端 B 便会建立不成功。而建立不成功就表明手机客户端 B 获得锁不成功，因此这个时候手机客户端 B 便会向 Zookeeper 申请注册自身的窃听器(Watcher)，监视 Key1 这一 ZNode 连接点的转变(当 Key1 连接点产生变化时，Zookeeper 会通告到手机客户端 B)。
?
假如手机客户端 A 和手机客户端 B，是另外要求到 Zookeeper，那麼 Zookeeper 它有一个体制，它会确保总是有在其中一个手机客户端能建立取得成功 Key1 这一 ZNode 连接点。
?
照片
图2
同样，这时手机客户端 C 来获得 Key1 锁时，也是没法获得到锁，也会把自己的 Watcher 申请注册到 ZK 中，监视 Key1 这一 ZNode 连接点的转变。
当手机客户端 A 解决完自身的领域模型以后，那麼便会实行释放出来锁的实际操作。释放出来锁时，手机客户端删掉 Key1 连接点，假如连接点删掉取得成功就表明锁释放出来取得成功。当 Key1 这一连接点被删掉后，Zookeeper 便会通告全部监视 Key1 这一连接点的手机客户端，也就是手机客户端 B、C。
当手机客户端 B 和 C 收到通告之后，了解 Key1 连接点发生了转变，这个时候他们便会再次去要求 Zookeeper，试着在 locks 文件目录下边建立 Key1 连接点，这个时候也总是有一个手机客户端能取得成功建立 Key1 连接点。倘若说成手机客户端 B 建立成功了，那麼就表明手机客户端 B 取得成功获得到锁.手机客户端 C 获得锁不成功，那麼就再次去监视 Key1 这一连接点的转变。
照片
图3
为什么不强烈推荐
之上便是根据临时性连接点这一计划方案去完成 Zookeeper 分布式锁，可是这一计划方案一般不是被强烈推荐的。为什么呢?这是由于应用这一计划方案会存有一个非常大的难题：从众效应。
啥意思呢?
从上边的全过程中我们可以见到，当手机客户端 A 释放出来锁取得成功之后，Zookeeper 必须去通告全部监视 Key1 这一连接点的手机客户端。上边大家的事例中仅有手机客户端 B 和手机客户端 C，可是在具体运用中很有可能有不计其数个手机客户端，乃至大量。Zookeeper 在这一瞬间必须推送不计其数个要求，最先这一高效率显而易见不是高的，此外当分布式锁的市场竞争比较猛烈时，极有可能在这一瞬间 Zookeeper 的网口很有可能被撑爆。并且系统软件中很有可能并不仅存 Key1 这一把锁，还会继续存有 Key2、Key3、Key4...，这种锁也会存有市场竞争，Zookeeper 的工作压力会更高。
在这个全过程中，大家很显著地能觉得到它是不科学的，由于获得分布式锁时肯定是仅有在其中一个手机客户端能获得到，那麼当 Key1 这一连接点被删掉之后，必须通告别的的手机客户端来获得锁，这个时候大家必须去通告全部的手机客户端吗?
显而易见是沒有必需的，大家只必须通告在其中一个手机客户端就可以了。因而计划方案二发生了。
计划方案二：根据临时性次序连接点完成(强烈推荐)
根据临时性次序连接点去完成分布式锁时，就并不是在 Linux 这一文件目录下边建立 Key1 这一临时性连接点了。只是先在 locks 这一文件目录下边建立一个 Key1 文件目录，随后在 Key1 文件目录里边去建立临时性次序连接点。
假定如今手机客户端 a 来获得分布式锁 Key1，那麼这个时候手机客户端 A 便会在 Key1 这一文件目录里边建立一个临时性次序连接点，这一临时性次序连接点的编号是 001。
随后手机客户端 A 会分辨自身建立的这一临时性次序连接点 001 在 Key1 这一文件目录里边，它的编号是否最少的?如果是最少的，那麼就表明手机客户端 A 获得锁取得成功。
然后手机客户端 B 也来获得 Key1 这一分布式锁，它也会在 Key1 这一文件目录下边去建立一个临时性次序连接点，因为这个时候自增编号早已变成 002 了，由于以前早已建立过 001 了，因此手机客户端 B 会建立 002 这一临时性次序连接点。
照片
图4
同样，手机客户端 B 也会分辨自身当今建立的临时性次序连接点 002，是否当今 Key1 文件目录中编号最少的临时性连接点，显而易见并不是，由于前边有一个 001 临时性次序连接点，因此手机客户端 B 这个时候是获得锁不成功。
当手机客户端 B 获得锁不成功以后，它会把自己的窃听器申请注册到 Zookeeper，它监视的是它前边一个临时性次序连接点，也就是 001 这一次序连接点。
照片
图5
这时假如手机客户端 C 也来获得分布式锁 Key1，这个时候它便会在 Key 文件目录中建立临时性次序连接点 003，一样 003 也不是编号最少的临时性次序连接点，因此手机客户端 C 也获得锁不成功，然后它会去监视 002 这一临时性次序连接点。
当手机客户端 A 解决完领域模型以后，它便会去释放出来锁。释放出来锁的实际操作便是去删掉 Key1 这一文件目录下边手机客户端 A 所建立的临时性次序连接点，也就是删掉 001 这一临时性次序连接点。当 001 这一次序连接点被删掉之后，Zookeeper 便会去通告监视 001 这一次序连接点的全部手机客户端，也就是通告手机客户端 B。手机客户端 B 接受到 Zookeeper 的通告以后，它便会去分辨我当今建立的临时性次序连接点 002 是否当今 Key1 这一文件目录中编号最少的一个临时性次序连接点。这时因为 001 这一次序连接点早已不会有了，显而易见 002 是最少的了，因而手机客户端 B 就获得锁取得成功。
照片
图6
一样当手机客户端 B 释放出来锁以后，便会将 002 删掉，002 删掉之后，Zookeeper 会通告手机客户端 C，手机客户端 C 发觉我当今建立的临时性次序连接点 003 是 Key1 这一文件目录里边最少的编号，因此手机客户端 C 获得锁取得成功。
思索
当手机客户端 A 获得锁取得成功之后，长期不释放出来锁，换句话说手机客户端 A 所属的设备服务器宕机，或是手机客户端 A 所属的设备发生网络问题，这个时候会发生哪些情况?
当手机客户端 A 所属的设备发生服务器宕机，或是发生网络问题后，长期不和 Zookeeper 通讯的情况下，手机客户端 A 和 Zookeeper 中间建立的 Session 便会无效，当这一 Session 无效之后，Zookeeper 会将手机客户端 A 所建立的临时性次序连接点给立即删掉，这个时候别的的手机客户端就能一切正常获得锁了。
