标签：父节点   系统   targe   用户访问   没有   简单   target   客户   持久   

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

详解Zookeeper原理与应用场景

标签：父节点   系统   targe   用户访问   没有   简单   target   客户   持久   

原文地址：https://www.cnblogs.com/zhengbin/p/10401058.html