详解Zookeeper原理与应用场景
Zookeeper 分布式协调服务
应用之处：发布、订阅，命名服务，分布式协调和分布式锁
对比 Chubby：
Chubby 被定义为 分布式的锁服务
为分布式系统提供 松耦合、粗粒度 的分布式锁功能
其由两部分组成
提供数据的读写接口并管理相关配置数据的服务端
另一部分是客户端使用的 SDK
为对外提供稳定服务，每一个 Chubby 单元都由一组服务器组成，使用共识算法从集群中选举出主节点
实现原理：
文件系统：
Zookeeper 也使用文件系统组织系统中存储的资源
-
/parent
-
/parent/node1
-
/parent/node2
-
/parent/node3
其并没有文件和文件夹的概念，只有 Znode 概念，它既可以作为容器存储数据，也可以持有其他 Znode 形成父子关系
Znode 有四种类型：
-
PERSISTENT：持久
-
persistent_sequential：持久且有序
-
ephemeral：临时
-
ephemeral_sequential：临时且有序
临时节点：
客户端连接 Z 时才会保持存在的节点，当客户端和服务端连接中断，则当前连接持有的所有节点都会被删除
持久节点：
与临时节点相反，不会随会话连接的中断而删除，需要客户端主动删除
顺序性：
如果使用 Z 的顺序节点，那么所有节点就会在名字的末尾附加一个序列号，序列号是由父节点维护的单调递增计数器生成
临时/持续节点：
通知实现原理：
实现分布式排他锁：
第一种，通过创建临时 Znode 简单实现：
第二种，通过创建临时顺序 Znode 实现：
第三种，解决第二种的羊群效应：
-
客户端连接 Zookeeper，并在 /lock 下创建临时且有序（即EPHEMERAL_SEQUENTIAL）的子节点，如，第一个子节点为 /lock/lock-000，第二个为 /lock/lock-001，以此类推；
-
创建成功后，获取 /lock 下的子节点列表，判断刚创建的子节点在列表中是否是序号最小的子节点，如果是，则认为是获得锁，否则，监听刚创建的子节点的前一位子节点的删除消息，等获得该子节点的变更通知后，重复此步骤，直至获得锁为止；
-
执行业务代码；
-
完成业务代码后，删除对应子节点释放锁；
与 Redis 实现分布式锁比较：
-
Redis 需要自己实现重试逻辑，比较消耗性能；
-
zk 重试获取锁，对节点注册监听器即可，不需要主动尝试，性能开销小；
-
如果 Redis 获取锁的客户端挂了，就不能主动删除 key，只能等待 key 的超时到期，而 zk 会主动发现客户端断连，并将临时 znode 删除，触发后面的监听器逻辑
实现分布式共享锁：
扩展：
DNS：
-
DNS（Domain Name System，域名系统），万维网上作为域名和 IP 地址相互映射的一个分布式数据库，方便用户访问互联网，无需记住能够被机器直接读取的 IP 数串。
-
通过域名，最终得到该域名对应的 IP 地址的过程叫做域名解析。
-
DNS 协议运行在 UDP 协议智商，使用端口号 53。
