详解Zookeeper原理与应用场景

Zookeeper 分布式协调服务

应用之处：发布、订阅，命名服务，分布式协调和分布式锁

对比 Chubby：

Chubby 被定义为 分布式的锁服务

为分布式系统提供 松耦合、粗粒度 的分布式锁功能

其由两部分组成

提供数据的读写接口并管理相关配置数据的服务端

另一部分是客户端使用的 SDK

为对外提供稳定服务，每一个 Chubby 单元都由一组服务器组成，使用共识算法从集群中选举出主节点

实现原理：

文件系统：

Zookeeper 也使用文件系统组织系统中存储的资源

• /parent

• /parent/node1

• /parent/node2

• /parent/node3

其并没有文件和文件夹的概念，只有 Znode 概念，它既可以作为容器存储数据，也可以持有其他 Znode 形成父子关系

Znode 有四种类型：

1. PERSISTENT：持久

2. persistent_sequential：持久且有序

3. ephemeral：临时

4. ephemeral_sequential：临时且有序

临时节点：

客户端连接 Z 时才会保持存在的节点，当客户端和服务端连接中断，则当前连接持有的所有节点都会被删除

持久节点：

与临时节点相反，不会随会话连接的中断而删除，需要客户端主动删除

顺序性：

如果使用 Z 的顺序节点，那么所有节点就会在名字的末尾附加一个序列号，序列号是由父节点维护的单调递增计数器生成

临时/持续节点：

通知实现原理：

实现分布式排他锁：

第一种，通过创建临时 Znode 简单实现：

第二种，通过创建临时顺序 Znode 实现：

第三种，解决第二种的羊群效应：

1. 客户端连接 Zookeeper，并在 /lock 下创建临时且有序（即EPHEMERAL_SEQUENTIAL）的子节点，如，第一个子节点为 /lock/lock-000，第二个为 /lock/lock-001，以此类推；

2. 创建成功后，获取 /lock 下的子节点列表，判断刚创建的子节点在列表中是否是序号最小的子节点，如果是，则认为是获得锁，否则，监听刚创建的子节点的前一位子节点的删除消息，等获得该子节点的变更通知后，重复此步骤，直至获得锁为止；

3. 执行业务代码；

4. 完成业务代码后，删除对应子节点释放锁；

与 Redis 实现分布式锁比较：

1. Redis 需要自己实现重试逻辑，比较消耗性能；

2. zk 重试获取锁，对节点注册监听器即可，不需要主动尝试，性能开销小；

3. 如果 Redis 获取锁的客户端挂了，就不能主动删除 key，只能等待 key 的超时到期，而 zk 会主动发现客户端断连，并将临时 znode 删除，触发后面的监听器逻辑

参考

实现分布式共享锁：

扩展：

DNS：

• DNS（Domain Name System，域名系统），万维网上作为域名和 IP 地址相互映射的一个分布式数据库，方便用户访问互联网，无需记住能够被机器直接读取的 IP 数串。

• 通过域名，最终得到该域名对应的 IP 地址的过程叫做域名解析。

• DNS 协议运行在 UDP 协议智商，使用端口号 53。

共识算法：

Raft

参考

https://draveness.me/zookeeper-chubby