Zookeeper概述

什么是Zookeeper

zookeeper,英/'zuːkiːpə/,动物园管理员,将分布式系统比作动物园,那么Zookeeper就是用来管理分布式应用的。

其官方定义为(本人根据官网内容翻译如下):

是一个开源的分布式应用的服务,提供了更高级别的服务,包括:同步、配置维护、分组和命名。
主要目标:通过与标准文件系统一致的组织结果的命名空间,允许分布式进程之间可以进行同步。
功能:提供了优质的高性能、高可用性、和严格有序的访问。

集群结构

类似其他分布式工具,Zookeeper是支持复制的,由一系列的Server组成,Client与Server相连以获取相关的服务。
在这里插入图片描述
集群结构说明:

集群数量为奇数,并且超过N+1台,只要集群中大多数节点都处于可用状态,那么集群就是可用的,集群中的服务器角色有:
1)领导者:复杂投票的发起和决议,并更新系统状态
2)学习者:包括跟随者和观察者,从Leader处获取最新的系统状态
3)Follower用于接受客户端请求,并向客户端返回结果,在选举过程中参与投票
4)Observer观察者可以接受客户端请求,将写请求转发给Leader,但是不参与投票,只同步状态。它的目的是为了扩展系统,以提高读取速度。

集群中由一个Leader节点和N个Follower节点组成,所有的Server之间能彼此通信,并且在各自内存中维护了状态图,与之一致的事务日志和快照位于持久化存储中。这一点类似Redis的Sentinel模式,它们都具有高度的自治能力,一旦Leader节点不可达,则自动完成新Leader的选举并恢复服务。

数据模型和命名空间

Zookeeper提供的命名空间与标准的文件系统非常类似,一个名称就是一个由“/”分割的路径序列,其层级结构为:
在这里插入图片描述
跟Linux的标准文件系统的结构是一致的;每一个节点就是一个路径。

节点和临时节点

Zookeeper的节点有两种:节点和临时节点:
第一种,节点znode,其特点为:
1、跟标准文件系统不一样的是,Zookeeper的每个命名空间,还关联数据,也跟它的孩子一样。这就好比在一个文件系统中,允许一个文件同时也作为一个文件目录。

2、Zookeeper被设计为存储协调数据,通常存储在每个节点中的数据通常很小,zookeeper的数据节点通常被成为znode.

3、znodes维护了一个状态结构,包含版本、ACL、时间戳,用以验证和协调更新。每次数据发生变化,版本号就会增加。

4、每个命名空间中的znode的读和写都是自动的;每个节点都有一个ACL限制列表。

另一类是临时节点
Zookeeper有一个临时节点的概念,这些节点只在创建他们的会话活动期间,当会话结束的时候,这些节点就被删除,临时节点在实现tbd时是有用的。
【这里的tdb是什么,官网没有说明,也没搜到相关资料】

有条件地更新和监控

Zookeeper支持监控,即客户端可以设置在某个znode上的监控;当一个节点发生变化时,就会触发和删除一个监控。当一个监控触发时,客户端会收到一个说明节点变化的包。

当客户端和Zookeeper Server断开时,客户端将收到一个本地通知。
本质就是:监听器(观察者模式)

各种保证

Zookeeper之所以能构造复杂的服务,如同步、配置管理、组管理等功能,是因为它提供了一系列的保证:
1)顺序一致性:客户端的更新操作必须与它们被发送的顺序严格一致
2)原子性:更新操作要么成功、要么失败
3)单个系统影像:一个客户端将会看到相同的服务视图,不管它与那个Server连接(跟一致性是呼应的)
4)可靠性:一旦一个更新操作被应用,从更新时间点向前的时间都将报错一致,直到下一次更新。
5)时间轴:在一个特定的时间点上,客户端看到的系统视图被保证是最新的。

API种类

zk的操作特别少,执行help指令,可以看到全部API:
在这里插入图片描述

Zookeeper组件结构

在这里插入图片描述
除了request processor, 组成zookeeper服务的每个server都会在本地备份其它组件的拷贝(应该是Leader的复本)。

复制数据库是一个内存数据库,保存了所有的数据树;更新操作被记录到磁盘中,便于数据恢复;写操作在应用于内存数据库之前先被序列化到磁盘上了。
也就是说磁盘上的日志才是数据正真的现状。

读写分离流程

每一个Zookeeper服务器都能为客户端服务,客户端连接到具体某个服务器后并提交请求。读请求直接由本地每个服务器数据库的备份来满足(直接由提供Zookeeper服务器的内存数据);而那些可能改变服务状态的请求,即写请求,通过一致性协议Zab(Zookeeper Atomic Broadcast)来处理。

一致性协议的处理流程:来自客户端的写请求被统一发送到一leader节点,其他的追随者节点,接受Leader节点的消息建议,并同意消息发送。消息层负责Leader失败时替换Leader,和同步追随者和Leader。

Zookeeper使用一个议客户原子消息协。因为消息层是原子的,Zookeeper可以保证本地复制从来不会有分歧。当Leader节点收到写请求时,它会计算当前系统的写操作被应用时的状态,并且将其转换成一个捕获了最新状态的事务。

Zookeeper Transactions是有序的、Zookeeper是快速的(在10:1的读写比例下,在读优先的工作量下,表现是较好的)。

Zookeeper相关应用

Zookeeper诞生的背景:拆分系统带来了系统的复杂性,系统之间的交互需要提供统一的服务进行协调,Zookeeper作用是提供一个工具集,用来建立安全处理局部故障的分布式应用。

它是一个分布式小文件系统,并且被设计为高可用的,通过选举算法和集群复制以避免单点故障。它是文件系统,所以技术节点挂掉,也不会丢失数据,重启服务数据即可恢复。节点更新是原子操作的,通过版本号,实现了更新的乐观锁;当版本号不匹配时,整个操作失败并回滚。

Zookeeper为开发者提供了保障,其相关应用有:
1)Hadoop,使用ZK的事件处理,确保整个集群中只有一个NameNode,存储配置信息等。
2)HBase,使用ZK的事件处理确保整个集群只有一个HMaster,觉察HRegionServer联机和宕机,存储访问控制列表等。
3)它是Apache的一个项目,诞生于雅虎消息代理的协调和故障恢复服务,是一个高度可扩展的发布-订阅系统。

Zookeeper应用场景

zookeeper的应用场景:
1)配置管理:分布式应用中的统一配置管理,提供集中服务配置管理功能,应用场景HBase,控制集群配置信息;Kafka消息队列,使用Zookeeper,管理Broker(经纪人)
Alibaba的服务器治理框架Dubbo,利用zookeeper来管理一些服务配置。
2)命名管理:跟域名类似的功能,类似域名管理的;如果应用中需要服务和IP的映射关系的配置,也可以统一集中管理。
3)分布式锁服务:HBase的HMaster的使用。
4)集群管理:用于管理在线集群信息

启示录

1、Zookeeper其一致性保证的实现过程,本质就是Paxos算法的应用。
2、分布式组件都有一些相通的设计思想,如数据分区、一致性保证等,前一段时间玩过Redis的Sentinel集群实践,再回头看Zookeeper的时候,发现它俩自动选举Leader进行故障修复的流程是一样的。

官网罗列的使用Zookeeper的软件产品中,就有redis-failover,原来是Redis的故障处理流程是基于Zookeeper的。Zookeeper提供的主要服务就是统一配置、选举、监听等,所以使用它的产品主要主要用它来实现消息的发布订阅、主节点的选举、配置更新等功能。

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 代码科技 设计师:Amelia_0503 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值