Hadoop系列 (七)：ZooKeeper详细介绍

最新推荐文章于 2024-05-07 07:34:25 发布

EricRae

最新推荐文章于 2024-05-07 07:34:25 发布

阅读量3.1k

点赞数 4

分类专栏： # hadoop 文章标签： hadoop zookeeper big data

本文链接：https://blog.csdn.net/EricLeiy/article/details/120829713

版权

Hadoop系列文章

Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等等。

从设计模式角度来说，是基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

Zookeeper中的角色主要有以下三类：

在这里插入图片描述

Zookeeper：一个领导者（leader），多个跟随着（Follower）组成的集群。
可靠性：集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。如果消息被推送到一台服务器接收，那么它将被所有的服务器接收。
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
顺序性：更新请求顺序进行，来自一个Client的更新请求按其发送的顺序依次执行。包括全局有序和偏序两种，全局有序是指如果在一台服务器上消息a在消息b之前发布，则所有的Server上消息a都将消息b之前发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
原子性：数据更新原子性，一次数据更新要么成功，要么失败。
实时性：在一定范围内，Client能读到最新数据。zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息，但由于网络延时等原因，zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync接口。
等待无关：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

Zookeeper数据模型的结构与Unix文件系统很类似，整体上可以看做是一棵树，每个节点称作一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。

ZNode类型：

Zookeeper中znode的节点创建时候是可以指定类型的，主要有下面几种类型。

ZNode类型	描述
PERSISTENT	持久化znode节点，一旦创建这个znode点存储的数据不会主动消失，除非是客户端主动的delete。
SEQUENCE	顺序增加编号znode节点，任意Client来创建这个znode都会得到一个比当前zookeeper命名空间最大znode编号+1的znode，也就说任意一个Client去创建znode都是保证得到的znode是递增的，而且是唯一的。
EPHEMERAL	临时znode节点，Client连接到zk service的时候会建立一个session，之后用这个zk连接实例创建该类型的znode，一旦Client关闭了zk的连接，服务器就会清除session，然后这个session建立的znode节点都会从命名空间消失。也就是说，这个类型的znode的生命周期是和Client建立的连接一样的。
PERSISTENT\|SEQUENTIAL	顺序自动编号的znode节点，这种znoe节点会根据当前已近存在的znode节点编号自动加 1，而且不会随session断开而消失。
EPHEMERAL\|SEQUENTIAL	临时自动编号节点，znode节点编号会自动增加，但是会随session消失而消失。

Zookeeper 的核心是广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

恢复模式（选主）：当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。
广播模式（同步）：状态同步保证了leader和Server具有相同的系统状态。为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数 。

每个Server在工作过程中有三种状态：

LOOKING： 当前Server不知道leader是谁，正在搜寻。

LEADING： 当前Server即为选举出来的leader。

FOLLOWING： leader已经选举出来，当前Server与之同步。