大数据Hadoop之ZooKeeper认识

Posted 2023-04-22

参考技术A Zookeeper字面上理解就是动物管理员，Hadoop生态圈中很多开源项目使用动物命名，那么需要一个管理员来管理这些“动物”。

在集群的管理中Zookeeper起到非常重要的角色，他负责分布式应用程序协调的工作。

Zookeeper管理集群会选举一个Leader节点（可参考FastLeader选举算法，即快速选举Leader节点），Leader节点主要负责整个Zookeeper集群的运行管理，Follower负责管理具体的数据存储与读取。

Zookeeper主要提供以下四点功能：统一命名服务、配置管理、集群管理、共享锁和队列管理，用于高效的管理集群的运行。

1. 统一命名服务

命名服务指通过指定的名字获取资源或者服务提供者的信息。分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于识别和记忆。通常情况下使用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，即对人友好又不会重复。

Zookeeper集群中统一由Leader节点（图中M节点）来管理所有Follower节点（图中的S1和S2节点）的命名空间。Zookeeper提供统一的命名服务，他不对外提供数据也不存储数据，他只提供一套统一的命名规则，运行在Zookeeper之上的服务需要遵循这一套命名规则。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的接口（API），能够很容易创建一个全局唯一的路径（path），这个path就可以作为一个名称。命名服务（NameService）已经是Zookeeper内置的功能，你只要调用Zookeeper的API就能实现。如调用create接口就可以很容易创建一个目录节点。

遵循Leader统一管理命名规则下，集群中数据读写的方式：

1.1.写数据，一个客户端进行写数据请求时，会指定Zookeeper集群节点，如果是Follower接收到写请求，会把请求转发给Leader，Leader通过内部的Zab协议进行原子广播，直到所有Zookeeper节点都成功写了数据，然后Zookeeper会给Client发回写完响应。

1.2.读数据，因为集群中Zookeeper按照统一的命名空间，所有Zookeeper节点呈现相同的命名空间视图（文件目录名称结构），所以读数据的时候请求任意一台Zookeeper节点都一样。

2. 配置管理

配置的管理在分布式应用环境中很常见，例如同一个应用需要在多台服务器上运行，但是它们的应用系统的某些配置相同的，如果要修改这些相同的配置项，就必须同时修改每台运行这个应用系统的PC Server，这样非常麻烦而且容易出错。像这样的配置信息完全可以交给Zookeeper来管理，处理起来非常便捷。

配置的管理包含发布和订阅两个过程，顾名思义就是将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中管理和动态更新。

如图所示，将配置信息保存在Zookeeper（Leader节点）的某一个目录中，然后将所有需要修改的应用机器订阅该Zookeeper（Leader节点）节点，一旦Leader节点发布新配置信息，每台订阅的机器就会收到Zookeeper的通知，然后从Zookeeper获取新的配置信息应用到系统中，完成配置的集中统一管理。

3. 集群管理

Zookeeper在集群管理中主要是集群监控和Leader选举。

3.1.集群管理

这通常用于那种对集群中机器状态、 ， 机器在线率有较高要求的场景，能够快速对集群中机器变化做出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器自己定时向监控系统汇报"我还活着"。

这种做法可行，但是存在两个比较明显的问题：

1）.集群中机器有变动的时候，牵连修改的东西比较多。

2）.有一定的延时。

利用ZooKeeper中两个特性，就可以实施另一种集群机器存活性监控系统：

1）.客户端在示例节点A上注册一个监控者（Watcher），那么如果A的子节点变化了，会通知该客户端。

2）.创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

3.2.Leader选举：

Leader选举即从大量集群节点中选举一个Leader节点，是zookeeper中最为经典的使用场景，在分布式环境中选举的Leader节点好快会直接影响集群的效率。Leader节点主要负责相同的业务应用分布在不同的机器上共用的逻辑模型和数据的调配，优秀的调配方案可以大大减少重复运算，提高性能降低集群的负载。

利用ZooKeeper中两个特性，就可以实施另一种集群中Leader选举：

1）.利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建Leader节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群的Leader选举了。

2）.另外，这种场景演化一下，就是动态Leader选举。这就要用到EPHEMERAL_SEQUENTIAL类型节点的特性了，这样每个节点会自动被编号。允许所有请求都能够创建成功，但是创建节点会为每个节点安排顺序，每次选取序列号最小的那个机器作为Leader。

小结

Zookeeper作为Hadoop主要的组件，在集群管理方面为我们提供了解决方案。通过对统一命名服务、配置管理和集群管理的阅读，我们能够清晰的理解Zookeeper的核心内容。针对共享锁和队列服务偏技术实现，有兴趣的可以进一步研究。

Zookeeper在大数据集群中解决集群管理的问题，磨刀不误砍柴工，了解完工具我们下一次分享一些具体的实效应用。

大数据开发之zookeeper简介

首先安装hadooper必须安装zookeeper。

zookeeper在hadoop生态圈中起的非常重要的作用，一句话就是ZooKeeper是分布式系统中的协调系统。
浅谈zookeeper:zookeeper是什么？
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，
是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：
配置维护、域名服务、分布式同步、组服务等。
zookeeper的特点
简单
ZooKeeper的核心是一个精简的文件系统，它支持一些简单的操作和一些抽象操作，例如，排序和通知。
丰富
ZooKeeper的操作是很丰富的，可实现一些协调数据结构和协议。例如，分布式队列、分布式锁和一组同级别节点中的“领导者选举”。
高可靠
ZooKeeper支持集群模式，可以很容易的解决单点故障问题。
松耦合交互
不同进程间的交互不需要了解彼此，甚至可以不必同时存在，某进程在ZooKeeper中留下消息后，该进程结束后其它进程还可以读这条消息。
资源库
ZooKeeper实现了一个关于通用协调模式的开源共享存储库，能使开发者免于编写这类通用协议。
zookeeper扮演的角色
领导者(leader)：负责进行投票的发起和决议，更新系统状态。
学习者(learner)：包括跟随者(follower)和观察者(observer)
follower：用于接受客户端请求并向客户端返回结果，在选举过程中参与投票。
Observer：可以接受客户端连接，将写请求转发给leader，但observer不参与投票过程，只同步leader的状态，observer的
目的是为了扩展系统，提高读取速度。
客户端(client)：请求发起方。
zookeeper的数据模型
层次化的目录结构，命名符合常规文件系统规范
每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
节点znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
客户端应用可以在节点上设置监视器
节点不支持部分读写，而是一次性完整读写
zookeeper的节点类型
ZooKeeper节点znode有两种类型，临时节点(ephemeral)和持久节(persistent)。znode的类型在创建时确定并且之后不能再修改。
ephemeral节点在客户端会话结束时，将会被zookeeper删除，并且ephemeral节点不可以有子节点。
persistent节点不依赖与客户端会话，只有当客户端明确要删除该persistent节点时才会被删除。
目前znode有四种形式的目录节点，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL
znode可以是临时节点，一旦创建这个znode的客户端与服务器失去联系，这个znode也将自动删除，
ZooKeeper的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，
这个连接状态称之为session，如果znode是临时节点，这个seesion失效，znode也就删除了；持久化目录节点，这个目录节点存储的数据不会丢失；顺序自动编号的目录节点，这种目录节点会更具当前已经存放在的节点数自动加1，然后返回给客户端已经成功创建的目录节点名；临时目录节点，一旦创建这个节点的客户端和服务器端口也就是session超时，这种节点会被自动删除。