zookeeper基础知识点有哪些

本文主要讲解“动物园管理员的基本知识点有哪些”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“动物园管理员的基本知识点有哪些”！

一、zookeeper的概念

1、Zookeeper的基础概念

ZooKeeper的设计目标是封装那些复杂且容易出错的分布式一致性服务，形成高效可靠的原语集，并为用户提供一系列易于使用的接口。

ZooKeeper是一个典型的分布式数据一致性解决方案。分布式应用可以基于ZooKeeper实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

Zookeeper最常见的使用场景之一是作为服务生产者和服务消费者的注册中心。(例如，动物园管理员在Dubbo中扮演注册中心的角色)

2、Zookeeper重要概念：

Zookeeper本身就是一个分布式程序(只要超过一半的节点存活，Zookeeper就可以正常服务)

为了确保高可用性，最好以集群形式部署Zookeeper，这样只要集群中的大多数机器可用，Zookeeper本身就仍然可用。

Zookeeper将数据保存在内存中，这确保了高吞吐量和低延迟(但是内存限制了可以存储的容量，并且这个限制也得以保持)

动物园管理员是高性能的。特别是在“读”多于“写”的应用程序中的高性能，因为“写”将导致所有服务器之间的同步。

Zookeeper有临时节点的概念。当创建临时节点的客户端会话保持活动状态时，临时节点始终存在。当会话结束时，瞬时节点被删除。持久节点意味着一旦创建了znode，除非主动移除znode，否则znode将始终存储在zookeeper上。

实际上，zookeeper只提供了两个功能：1。管理(存储和读取)用户程序提交的数据2。提交用户程序和节点监控服务的数据。

3、会话（Session）

Session指的是ZooKeeper服务器和客户端之间的会话。在ZooKeeper中，客户端连接是指客户端和服务器之间的TCP长连接。当客户端启动时，它将首先与服务器建立一个TCP连接。从第一次连接建立开始，客户端会话的生命周期也开始了。通过这种连接，客户端可以通过心跳检测与服务器保持有效的会话，向Zookeeper服务器发送请求和接受响应，还可以通过这种连接从服务器接收Watch事件通知。会话超时值用于设置客户端会话的超时。当由于服务器压力过大、网络故障或客户端主动断开等各种原因导致客户端连接断开时，只要集群中的任何服务器都能在sessionTimeout中指定的时间内重新连接，之前创建的会话仍将有效。

* *在为客户端创建会话之前，服务器将首先为每个客户端分配一个会话ID。SessionID是Zookeeper会话的重要标识符，很多与会话相关的运行机制都是基于这个sessionID。因此，无论哪个服务器将sessionID分配给客户端，它都必须是全局唯一的。

00-1010当谈到分布时，我们通常说“节点”是指组成集群的每一台机器。但是，在Zookeeper中，“节点”分为两类。第一类也指组成集群的机器，我们称之为机器节点。第二种类型是指数据模型中的数据单元，我们称之为数据节点-ZNode。

动物园管理员将所有数据存储在内存中。数据模型是一棵树(Znode Tree)，用斜杠(/)划分的路径是Znode，如/foo/path2。每个都将保存自己的数据内容和一系列属性信息。

在Zookeeper中，节点可以分为持久节点和临时节点。所谓持久节点，就是一旦创建了ZNode，除非主动移除ZNode，否则ZNode将一直存储在Zookeeper上。临时节点不同，它的生命周期与客户端会话绑定在一起。一旦客户端会话失败，该客户端创建的所有临时节点都将被删除。此外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记了这个属性，Zookeeper将在创建节点时自动在节点名称后附加一个整数，这是一个由父节点维护的自增数字。

00-1010正如我们前面提到的，Zookeeper将在每个ZNode上存储数据。对应于每个ZNode，Zookeeper将为其维护一个名为Stat的数据结构。在Stat中，记录了这个ZNode的三个数据版本，即版本(当前ZNode版本)和版本(当前ZNode

子节点的版本）和 aversion（当前ZNode的ACL版本）。

6、 Watcher

Watcher（事件监听器），是Zookeeper中的一个很重要的特性。Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性。

7、 ACL

Zookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。Zookeeper 定义了如下5种权限。

其中尤其需要注意的是，CREATE和DELETE这两种权限都是针对子节点的权限控制。

二、ZooKeeper 特点

• 顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。

• 原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。

• 单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。

• 可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

三、ZooKeeper 设计目标

3.1 简单的数据模型

ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。 名称空间由 ZooKeeper 中的数据寄存器组成 - 称为znode，这些类似于文件和目录。 与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

3.2 可构建集群

为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。 客户端在使用 ZooKeeper 时，需要知道集群机器列表，通过与集群中的某一台机器建立 TCP 连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。

**ZooKeeper 官方提供的架构图：

上图中每一个Server代表一个安装Zookeeper服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过 Zab 协议（Zookeeper Atomic Broadcast）来保持数据的一致性。

3.3 顺序访问

对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。 这个编号也叫做时间戳——zxid（Zookeeper Transaction Id）

3.4 高性能

ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

四 ZooKeeper 集群角色介绍

最典型集群模式： Master/Slave 模式（主备模式）。在这种模式中，通常 Master服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。如下图所示

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

五 ZooKeeper &ZAB 协议&Paxos算法

5.1 ZAB 协议&Paxos算法

Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。

5.2 ZAB 协议介绍

ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

5.3 ZAB 协议两种基本的模式：崩溃恢复和消息广播

ZAB协议包括两种基本的模式，分别是 崩溃恢复和消息广播。当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。

当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。 当一台同样遵守ZAB协议的服务器启动后加人到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加人的服务器就会自觉地进人数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。正如上文介绍中所说的，ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理。Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。

到此，相信大家对“zookeeper基础知识点有哪些”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！