详解Zookeeper原理与应用场景

Zookeeper 分布式协调服务

应用之处:发布、订阅,命名服务,分布式协调和分布式锁html

对比 Chubby:

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

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

其由两部分组成git

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

另外一部分是客户端使用的 SDKredis

为对外提供稳定服务,每个 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

相关文章
相关标签/搜索