1、zookeeper整体概述

最新推荐文章于 2022-07-11 17:01:40 发布

江城子v3

最新推荐文章于 2022-07-11 17:01:40 发布

阅读量173

点赞数

分类专栏： Zookeeper原理解析

本文链接：https://blog.csdn.net/jiang7chengzi/article/details/108228069

版权

Zookeeper原理解析专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1 简介

ZooKeeper是一个开源的分布式应用程序协调服务，提供了文件系统和通知机制，分布式应用程序可以基于它实现统一命名服务、应用配置管理、负载均衡、集群管理、分布式锁、队列管理等功能。

2 设计目的

最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
原子性：更新只能成功或者失败，没有中间状态。
顺序性：包括全局有序和偏序两种。全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

3 数据结构

Zookeeper会维护一个具有层次关系的数据结构，非常类似于一个标准的文件系统，如图所示：

Zookeeper这种数据结构有如下这些特点：

每个子目录项如 NameService 都被称作为znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1。
znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL（临时的）类型的目录节点不能有子节点目录。
znode 是有版本的（version），每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据，version 号自动增加。
znode的类型(4种)：Persistent 节点，一旦被创建，便不会意外丢失，即使服务器全部重启也依然存在。每个 Persist 节点即可包含数据，也可包含子节点。Ephemeral 节点，在创建它的客户端与服务器间的 Session 结束时自动被删除。服务器重启会导致 Session 结束，因此 Ephemeral 类型的 znode 此时也会自动删除。Persistent / Ephemeral Sequence 节点，创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时，都能创建成功，只是序号不同。
znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性，Zookeeper的很多功能都是基于这个特性实现的。
ZXID：每次对Zookeeper的状态的改变都会产生一个zxid（ZooKeeper Transaction Id），zxid是全局有序的，如果zxid1小于zxid2，则zxid1在zxid2之前发生。

4 watch机制

ZooKeeper可以为所有的读操作设置watch，包括：getData()、exists()及getChildren()。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次，这样可以减少网络流量。

数据watch(data watches)：getData和exists负责设置数据watch
子节点watch(child watches)：getChildren负责设置子节点watch

5 集群角色

在zookeeper集群当中，集群中的服务器角色分为Leader和Learner，Learner又分为observer和flollwer，如下：

在这里插入图片描述

具体功能如下：

leader(领导者)

为客户端提供读和写的功能，负责投票的发起和决议，负责系统的状态。

follower（跟随者）

为客户端提供读服务，如果是写的服务则转发给leader。在选举过程中进行投票。

observer(观察者)

为客户端提供读服务，如果是写服务就转发个leader。不参与leader的选举投票。也不参与写的过半原则机制。在不影响写的前提下，提高集群读的性能，此角色于zookeeper3.3系列新增的角色。

client（客户端）

连接zookeeper集群的使用者，请求的发起者，独立于zookeeper集群的角色。

6 应用场景

6.1 命名服务

这个似乎最简单，在zookeeper的文件系统里创建一个目录，即有唯一的path。在我们无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现，不见不散了。

阿里巴巴开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表。在Dubbo实现中：

服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。
服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址，并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。
另外，Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。

注意，Dubbo所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。

6.2 配置中心

发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。

程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。好吧，现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。在上面提到的应用场景中，有个默认前提是：数据量很小，但是数据更新可能会比较快的场景。

zookeeper简介

6.3 负载均衡

这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而使用方需要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件通过zookeeper做到生产者、消费者负载均衡。

生产者负载均衡：kafka发送消息的时候，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，因此kafka在运行过程中，会把所有broker和对应的分区信息全部注册到ZK指定节点上，默认的策略是一个依次轮询的过程，生产者在通过ZK获取分区列表之后，会按照brokerId和partition的顺序排列组织成一个有序的分区列表，发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。

消费负载均衡：在消费过程中，一个消费者会消费一个或多个分区中的消息，但是一个分区只会由一个消费者来消费。Kafka的消费策略是：

每个分区针对同一个group只挂载一个消费者。
如果同一个group的消费者数目大于分区数目，则多出来的消费者将不参与消费。
如果同一个group的消费者数目小于分区数目，则有部分消费者需要额外承担消费任务。
在某个消费者故障或者重启等情况下，其他消费者会感知到这一变化（通过 zookeeper watch消费者列表），然后重新进行负载均衡，保证所有的分区都有消费者进行消费。

6.4 集群管理

所谓集群管理无在乎两点：是否有机器加入和退出、选举master。

对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了。

对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。

zookeeper简介

6.5 分布式锁

有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。

对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

zookeeper简介