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提供的主要服务就是统一配置、选举、监听等，所以使用它的产品主要主要用它来实现消息的发布订阅、主节点的选举、配置更新等功能。

最后

以上就是彩色蛋挞为你收集整理的Zookeeper概述的全部内容，希望文章能够帮你解决Zookeeper概述所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。