ZooKeeper 架构原理

举报
Smy1121 发表于 2019/06/20 17:55:02 2019/06/20
【摘要】 ZooKeeper 是一个针对大型分布式系统的可靠协调系统;它提供的功能包括:配置维护、名字服务、分布式同步、组服务等; 它的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户; ZooKeeper 已经成为 Hadoop 生态系统中的基础组件。

ZooKeeper 是什么?

          ZooKeeper 是一个针对大型分布式系统的可靠协调系统;它提供的功能包括:配置维护、名字服务、分布式同步、组服务等; 它的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户; ZooKeeper 已经成为 Hadoop 生态系统中的基础组件。


ZooKeeper特点

ZooKeeper 主要包含以下几个特点:

1、最终一致性:为客户端展示同一视图,这是 ZooKeeper 最重要的性能。

2、可靠性:如果消息被一台服务器接受,那么它将被所有的服务器接受。

3、实时性:ZooKeeper 不能保证两个客户端同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。

4、等待无关(wait-free):慢的或者失效的 client 不干预快速的client的请求。

5、原子性:更新只能成功或者失败,没有中间其它状态。

6、顺序性:对于所有Server,同一消息发布顺序一致。


哪些系统用到了ZooKeeper?

主要有如下系统使用了ZooKeeper:

1、HDFS 文件存储系统。

2、下一代 Hadoop,Hadoop2.0即YARN。

3、Storm 实时计算框架。

4、HBase 分布式数据库。

5、Flume 流数据导入工具。

   

ZooKeeper 基本原理

ZooKeeper 架构

下面我们首先看一下 ZooKeeper 的架构图:

image.png

针对上面的 ZooKeeper 架构图,我们需要掌握以下几点内容。


1、每个Server 在内存中存储了一份数据。

2、ZooKeeper 启动时,将从实例中选举一个 leader(根据Paxos协议来选举,大家知道有这么个协议即可)。

3、Leader 负责处理数据更新等操作(这里用到Zab协议,大家知道有这么个协议即可)

4、一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。


Zookeeper 角色

Zookeeper中的角色主要有以下三类,如下表所示:

image.png


观察者(ObServer)

3.3.0版本新增了角色ObServer,那么为什么要引入ObServer角色呢?主要由于以下几种原因:

1、ZooKeeper 需保证高可用和强一致性。

2、为了支持更多的客户端,需要增加更多的Server。

3、Server增多会导致投票阶段延迟增大,影响性能。


ZooKeeper 权衡了伸缩性和高吞吐率,从而引入了ObServer角色。它的作用主要表现在以下几个方面:

1)ObServer 不参与投票过程,只同步 leader的状态。。

2)Observers 接受客户端的连接,并将写请求转发给 leader节点。

3)加入更多ObServer 节点,提高伸缩性,同时还不影响吞吐率。


ZooKeeper Server

我们从以下几个方面来理解 ZooKeeper Server:

1、Leader 选举算法采用了 Paxos 协议。


2、Paxos 核心思想是当多数 Server 写成功,则任务数据写成功。

1)如果有3个Server,则需两个写成功即表示任务数据写成功。

2)如果有4或5个Server,则需三个写成功即表示任务数据写成功。


3、Server 数目一般为奇数,例如 3、5、7等等。

1)如果有3个Server,则最多允许1个Server 挂掉。

2)如果有4个Server,则同样最多允许1个Server挂掉。


既然3个或者4个Server,同样最多允许1个Server挂掉,那么它们的可靠性是一样的,所以选择奇数个ZooKeeper Server即可,这里选择3个Server。



ZooKeeper 写数据流程

ZooKeeper 写数据的流程图如下所示:

image.png

ZooKeeper 的写数据流程主要分为以下几步:


1、比如 Client 向 ZooKeeper 的 Server1 上写数据,发送一个写请求。

2、如果Server1不是Leader,那么Server1 会把接受到的请求进一步转发给Leader,因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server,比如Server1和Server2, 各个Server写成功后就会通知Leader。

3、当Leader收到大多数 Server 数据写成功了,那么就说明数据写成功了。如果这里三个节点的话,只要有两个节点数据写成功了,那么就认为数据写成功了。写成功之后,Leader会告诉Server1数据写成功了。

4、Server1会进一步通知 Client 数据写成功了,这时就认为整个写操作成功。ZooKeeper 整个写数据流程就是这样的。


ZooKeeper 数据模型

下面是一个典型的ZooKeeper 数据模型。

image.png


ZooKeeper 它里面是如何组织用户数据的呢?下面让我们来一起学习;

1、ZooKeeper提供了一个层次化的目录结构,命名符合常规文件系统规范。

2、每个节点在ZooKeeper中叫做znode,并且它有一个唯一的路径标识。

3、节点Znode可以包含数据和子节点

4、Znode中的数据可以有多个版本,比如某一个路径下存有多个数据版本, 那么查询这个路径下的数据需带上版本号。

5、客户端应用可以在节点上设置监视器(Watcher)。

6、节点Znode不支持部分读写,而是一次性完整读写。

7、Znode 有两种类型:短暂的(ephemeral)和持久的(persistent)。

8、Znode的类型在创建时确定并且之后不能再修改。

9、短暂Znode的客户端会话结束时,ZooKeeper会将该短暂Znode删除,短暂的Znode不可以有子节点。

10、持久的Znode不依赖于客户端会话,只有当客户端明确要删除该持久Znode时才会被删除。

11、Znode有四种形式的目录节点,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL。


   

ZooKeeper 应用场景

统一命名服务

统一命名服务的命名结构图如下所示:

image.png


1、在分布式环境下,经常需要对应用/服务进行统一命名,便于识别不同服务。

1)类似于域名与ip之间对应关系,ip不容易记住,而域名容易记住。

2)通过名称来获取资源或服务的地址,提供者等信息。


2、按照层次结构组织服务/应用名称。

1)可将服务名称以及地址信息写到ZooKeeper上,客户端通过ZooKeeper获取可用服务列表类。


配置管理

配置管理结构图如下所示:

image.png


1、分布式环境下,配置文件管理和同步是一个常见问题。


1)一个集群中,所有节点的配置信息是一致的,比如 Hadoop 集群。

2)对配置文件修改后,希望能够快速同步到各个节点上。


2、配置管理可交由ZooKeeper实现。

1)可将配置信息写入ZooKeeper上的一个Znode。

2)各个节点监听这个Znode。

3)一旦Znode中的数据被修改,ZooKeeper将通知各个节点。


集群管理

集群管理结构图如下所示:image.png

image.png


1、分布式环境中,实时掌握每个节点的状态是必要的。

1)可根据节点实时状态做出一些调整。


2、可交由ZooKeeper实现。

1)可将节点信息写入ZooKeeper上的一个Znode。

2)监听这个Znode可获取它的实时状态变化。


3、典型应用

1)HBase中Master状态监控与选举。


分布式通知与协调

1、分布式环境中,经常存在一个服务需要知道它所管理的子服务的状态。

1)NameNode需知道各个Datanode的状态。

2)JobTracker需知道各个TaskTracker的状态。


2、心跳检测机制可通过ZooKeeper来实现。


3、信息推送可由ZooKeeper来实现,ZooKeeper相当于一个发布/订阅系统。


分布式锁

处于不同节点上不同的服务,它们可能需要顺序的访问一些资源,这里需要一把分布式的锁。分布式锁具有以下特性:

1、ZooKeeper是强一致的。比如各个节点上运行一个ZooKeeper客户端,它们同时创建相同的Znode,但是只有一个客户端创建成功。


2、实现锁的独占性。创建Znode成功的那个客户端才能得到锁,其它客户端只能等待。当前客户端用完这个锁后,会删除这个Znode,其它客户端再尝试创建Znode,获取分布式锁。


3、控制锁的时序。各个客户端在某个Znode下创建临时Znode,这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL,这样该Znode可掌握全局访问时序。


分布式队列

分布式队列分为两种:

1、当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。

1)一个job由多个task组成,只有所有任务完成后,job才运行完成。

2)可为job创建一个/job目录,然后在该目录下,为每个完成的task创建一个临时的Znode,一旦临时节点数目达到task总数,则表明job运行完成。


2、队列按照FIFO方式进行入队和出队操作,例如实现生产者和消费者模型。

【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200