ZooKeeper概念与应用

博客园首页 William 218浏览 0评论

Zookeeper是开源的分布式协调服务,提供了分布式数据一致性的解决方案。

Zookeeper 可用作配置中心和分布式锁服务,在 Dubbo、Kafka、Spark等分布式集群上得到广泛应用。

ZNode

Zookeeper的数据模型为树状结构,树的节点被称作ZNode。

Zookeeper使用路径来唯一标识ZNode,类似于Unix文件系统中的绝对路径。路径必须以/开头,由Unicode字符串组成,如/myapp/master/0

每一个ZNode维护着三部分数据:

  • stat: 节点状态信息,包括版本、更改时间、访问控制等
  • data: 节点的内容数据,Zookeeper限制每个节点数据不超过1M。Zookeeper设计用来进行协调调度,请勿在其中存放大量数据。
  • children: 该ZNode的子节点。

每个节点都有独立的访问控制列表(Access Control List, ACL), 来控制用户对本节点的访问权限。

每个ZNode都维护着三个版本号:

  • dataVersion: 节点数据版本号
  • cversion: 子节点版本号
  • aclVersion: 节点访问控制列表版本号

所有的写操作都会使相应的版本号增加。写操作必须指定要更新的ZNode的版本号,版本号不一致会导致写入失败。

Zxid

所有对Zookeeper状态的改变都会产生一个Zxid(ZooKeeper Transaction Id),Zxid全局有序。

Zxid为标识事件发生的先后顺序: 即事件A发生早于事件B,那么事件A的Zxid定小于事件B的Zxid。

每个ZNode维护两个Zxid:

  • cZxid: Znode创建
  • mZxid: Znode最近修改

Zxid是一个64位的数字, 高32位表示Zookeeper集群leader, 低32位表示逻辑顺序。每次leader改变后, 新产生的Zxid高32位都会改变。

节点类型

Zookeeper中的节点分为两种:

  • 临时节点: 临时节点依赖于创建节点的会话(Session), 一旦Session结束临时节点会被自动删除。临时节点不允许拥有子节点
  • 永久节点: 永久节点生存期不依赖于客户端会话,只有客户端执行删除操作时才会删除。

Zookeeper 可以创建顺序子节点,即创建子节点时在路径结尾添加一个自增的32位 id, 该id在该节点的父节点下是唯一的。

Watch

Zookeeper 所有的读操作getData(), getChildren()和 exists()都可以设置 Watch 触发器。

Watch 触发器是一次性的,当触发器通知了一次状态变化后消失,不会通知状态的再次变化。

Zookeeper 与客户端之间通过 Tcp Socket 进行通信, Zookeeper 会主动将时间通知客户端。

Zookeeper 保证客户端只有首先收到了Watch通知后,才会感知到它所设置监视的znode发生了变化。

Zookeeper 支持三种类型的watch:

  • exists: 被监视的Znode 创建、删除、数据改变时被触发
  • getData: 被监视的Znode 删除、数据改变时被触发
  • getChildren: 被监视的Znode 删除、创建子节点、删除子节点时被触发

Zookeeper 应用

ZooKeeper 是具有较高一致性的分布式协调服务,它提供以下保证:

  • 原子性: 所有操作具有原子性
  • 分布式一致性: 从任意节点中读取到的数据都是一致的
  • 顺序一致性: 从一个客户端来的更新请求会被顺序执行
  • 持久性: 写操作一旦成功,直到被覆盖为止持续有效

Zookeeper 使用数据副本和崩溃恢复机制保证数据安全和集群高可用性。

Zookeeper 使用基于 Paxos 算法的 ZAB协议(Zookeeper Atomic Broadcast)进行写操作,保证集群数据的一致性。

配置中心

我们可以将系统中通用配置信息写入 ZNode 中,客户端启动时从 Zookeeper 获取配置数据并监视配置节点的变化,当配置发生改变 Zookeeper 会通知所有的客户端获取最新数据,从而实现在线更新配置。

适合使用Zookeeper维护的配置通常:

  • 数据量较小
  • 在运行时动态发生变化
  • 各客户端读取到数据需要相同
  • 具有顺序一致性,客户端只要读取到新版本的数据,此后就不能读取到旧版本数据

当服务启动时,服务提供者可以在Zookeeper的相应路径下创建临时节点,并在节点中写入服务配置信息。服务关闭(崩溃)时,临时节点自动删除。

客户端启动时从 ZooKeeper 读取服务提供者信息从而实现自动的服务发布/移除功能。

分布式锁

Zookeeper 的临时节点可以维护客户端持有锁的状态,加锁失败的客户端可以使用 Watch 机制监视锁的释放情况,实现阻塞等待加锁。

Zookeeper 的顺序节点可以实现一个简单的队列,可以利用此特性实现公平锁。客户端在锁节点下创建顺序子节点,持有最小子节点的客户端成功加锁,加锁失败的客户端 Watch 前一个顺序子节点,从而实现先到先得的公平锁机制。

命名服务

ZooKeeper 的顺序节点可以生成全局唯一ID, 我们可以利用该ID为服务命名。相对于UUID, 该名称较短且可以保证绝不重复。

Master选举

与分布式公平锁应用类似,ZooKeeper 可以维护集群 Master。

集群中所有可以成为 Master 的进程都在 Zookeeper 中的指定路径下创建顺序子节点,持有最小子节点的进程成为Master。

集群中所有进程都 Watch 指定路径下节点的情况,一旦发生变化则重新读取最小子节点的持有者作为Master。

脑裂问题

传统集群实现方案是运行一个备用Master节点,备用Master节点定期向主Master节点发送ping请求,若能及时收到主Master的ack响应则认为正常。

若Ack响应超时,备用Master则会取代原主Master成为新的集群主Master节点。

若响应超时因为主Master故障导致,备用Master成为新的主节点完全正常。

若超时因为主备 Master 节点间 ping-ack 网络故障导致,那么主Master工作正常,而备用Master却误认为主Master崩溃而进行取代,那么集群中可能出现多个Master共存的故障(即脑裂故障)。

若使用 Zookeeper 维护 Master 信息,无论是因为主Master故障还是通信问题导致最小子节点被删除,备用Master持有的节点都会成为最小子节点。

此时,所有客户端都会受到通知并得知 Master 变更,保证集群中只有一个 Master。

当崩溃的Master恢复后,它将成为新的备用Master加入集群。

ZooKeeper 无法避免通信故障导致误判 Master 状态,但是可以保证在任何情况下集群中只有一个 Master 节点。


注:www2014.aspxhtml.com转载自cnblogs,若看不到图片,请移步来源网址查看。
via:https://www.cnblogs.com/Finley/p/9697237.html

转载请注明:AspxHtml学习分享网 » ZooKeeper概念与应用

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址