ZooKeeper

分布式协调服务
Zookeeper 是一个开源的分布式的,为分布式应用提供协调服务的 Apache 项目。ZooKeeper是一个分布式应用程序的协调服务,可以提供一组工具,可以在构建分布式应用时能够对部分失败进行正确处理,部分失败是分布式系统固有的特征
 
Zookeeper是采用ZAB一致性协议的用于进行分布式系统协同管理的分布式协同管理框架,它自身具有高度的可靠性、可扩展性和容错性,目标是基于自身去构建更为复杂的分布式应用,例如提供统一命名服务、分布式锁、分布式队列、选举、配置同步、心跳检查等功能。
假设程序是分布式部署在多台机器上,如果要改变程序的配置文件,需要逐台机器去修改,非常麻烦,
现在把这些配置全部放到zookeeper上去,保存在 zookeeper 的某个目录节点中,然后所有相关应用程序对这个目录节点进行监听,一旦配置信息发生变化,每个应用程序就会收到 zookeeper 的通知,然后从 zookeeper 获取新的配置信息应用到系统中。
概述Zookeeper
Zookeeper是一个开源的分布式服务协调框架,是Google Chubby组件的开源实现,是Hadoop和
HBase实现HA时的重要组件。
Zookeeper是一个高性能的分布式数据一致性解决方案。能将那些复杂的、容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并提供一系列简单易用的接口给用户使用
提供一系列原语操作服务,原语一般是指由若干条指令组成的程序段,用来实现某个特定功能,在
执行过程中不可被中断。可以基于这些原语服务构建高级别服务,例如分布式锁、配置管理、分布
式消息队列等设计上易于编码,数据模型构建在属性结构目录风格的文件系统中运行在Java环境上,同时支持Java和C语言
 ZooKeeper核心概念
Zookeeper的逻辑架构是典型的主从结构,包含Leader、Follower和Observer三种角色,ZK从众多的
Server服务中通过选举产生一个主控节点Leader,这台服务器为客户端提供读写服务;Follower和
Observer能够提供读服务,但在Leader选举过程和写操作的过半写功能策略Observer都是不参与的,
Observer用于单纯的提升集群的读性能。
 session会话机制
在ZooKeeper中一个客户端连接是指客户端和服务器之间的一个TCP长连接。当出现故障而又想要保存之前创建的会话时,只需要在sessionTimeout规定的时间内重新连接上集群的任意一台服务器即可ZooKeeper对外的服务端口默认是2181,当客户启动时新建立的TCP连接也将第一次启动,它能通过心跳检测与服务器保持有效会话,同时还会向ZK发送请求并接受响应,另外还能接收来自服务器的watch事件通知。
Zookeeper特点
Zookeeper工作在集群上,对集群提供分布式协调服务,它所提供的分布式协调服务具备的特点有:
最终一致性,不管客户端连接的是哪个Server,看到的是同一个视图
可靠性。如果一个消息被一个server接收,那么将被所有的server接收到
实时性。zk可以保证客户端在一个时间间隔范围内获取服务器更新的信息或者服务器失效信息,但
是由于网络延迟等问题不能保证两个客户端同时得到最新更新信息。如果需要最新信息,应在读数
据之前先调用sync接口
等待无关性。慢的或失效的客户端不会干预快速客户端的请求
原子性。对zk的更新操作要么成功,要么失败,没有中间状态
顺序性,包括全局服务器有序和客户端偏序,从服务器和客户端两方便保证消息的严格有序。
Zookeeper:一个领导者Leader、多个跟随者Follower组成的集群
集群中只要有半数以上节点存活,Zookeeper集群就能正常服务
全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个Server,数据都是一致的
更新请求顺序进行,来自同一个Client的更新请求按其发送顺序依次执行
数据更新原子性,一次数据更新要么成功,要么失败
Zookeeper核心特性
客户端发送的更新请求按照发送的顺序执行
更新操作只有成功或失败两种状态,不会存在其他状态
客户端连接到任意服务器看到是相同的数据视图
一旦一个更新操作被执行,则所有服务器都将执行这个更新动作
客户端看到的数据视图在一定时间内保证是最新的
 Zookeeper使用场景
zookeeper提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等
统一命名服务,每个znode都有一个对应的路径标识符
在分布式环境下,经常需要对应用/服务进行统一命名,便于识别。如IP不容易记住,而域名
容易记住
统一配置管理
分布式环境下,配置文件同步非常常见一般要求一个集群中,所有节点的配置信息是一致的,比如 Kafka 集群
对配置文件修改后,希望能够快速同步到各个节点上。
配置管理可交由ZooKeeper实现
可将配置信息写入ZooKeeper上的一个Znode
各个客户端服务器监听这个Znode
一旦Znode中的数据被修改,ZooKeeper将通知各个客户端服务器
统一集群管理
分布式环境中,实时掌握每个节点的状态是必要的
可根据节点实时状态做出一些调整
ZooKeeper可以实现实时监控节点状态变化
可将节点信息写入ZooKeeper上的一个ZNode
监听这个ZNode可获取它的实时状态变化
服务器动态上下线:客户端能实时洞察到服务器上下线的变化
心跳感知,创建临时节点
选举,创建一个相同的节点,只有一个客户端可以创建成功
软负载均衡
在Zookeeper中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请
求。
Zk基本结构
Zookeeper采用集群化部署方式,一般部署在多台服务器上,以防止单点失效。一般采用奇数2n+1台服务器部署,最多n个失效,目的是用于投票时收敛
zk服务器有两种角色,一种主节点Leader,负责投票的发起和决议,更新状态;一种是从节点,用于接
收客户端请求并向客户端返回结果,在选主过程中参与投票。为了控制网络开销,一般选择部分节点
follower进行投票,而其他节点称为observer,只观察结果进行同步。Observer 数量并不是越多越好,
一般与Follower数量相同。
客户端可以选择连接到zk集群中的每台服务器,而且每台服务器的数据完全一致,每个从节点与主节点进行通信,并同步主节点上更新的数据
1、半数机制:集群中半数以上机器存活,集群可用。所以 Zookeeper 适合安装奇数台服务器
2、Zookeeper 虽然在配置文件中并没有指定 Master 和 Slave。但是Zookeeper 工作时,是有一
个节点为Leader,其他则为 Follower,Leader 是通过内部的选举机制临时产生的。
ZK工作原理
zk的核心是原子广播,就是对zk集群上的所有主机发送数据包,通过这个机制保证各个节点之间的数据同步,实现这个机制是依赖zk中的一个内部协议,这个协议有恢复模式和广播模式两种。
Client与Server是通过NIO方式通信的
消息是FIFO方式执行的(顺序的,先进先出)
读消息可以通过zookeeper的leader和所有的follower
写消息必须通过leader。
当服务启动或者主节点崩溃后,协议进入恢复模式,当主节点再次被选举出来,且大多数服务端完成与
主节点的状态同步后,恢复模式结束,进入广播模式在广播模式下,所有节点接收客户端请求,所有的写请求转发给主节点,再由主节点发送广播给从节
点。当半数以上的从节点完成数据的写请求后,主节点才会提交这个更新【提交表示该数据可读,会首先每个从节点提供,然后主节点提交。收到提交请求才会将数据从磁盘再写入内存数据库,注意客户端请求是从内存数据库获取数据的】,然后客户端才会收到一个更新成功的响应。
Zookeeper的工作机制
Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
 ZK数据模型
Zookeeper采用层次化目录结构存储数据。目录就是节点,在zookeeper中称为Znode,并且有一个相
关联的访问控制列表ACL。注意:zk是使用小数据文件用来协调服务,而不是存储大容量数,所以一个
Znode存储的数据被限制在1MB依赖。
在ZooKeeper中节点是指数据模型中的数据单元,也叫数据节点Znode。数据模型是以树Znode Tree的格式进行存储,并通过斜杠/来分割路径,分割后的每个Znode都会保存自己的数据内容,同时还会保存一些列属性值,例如/zoo/path。Zookeeper通过共享一个分层的命名空间来相互协同,这个类似属性目录结构的所有节点均称为Znode,可以直接挂载数据,也可以嵌套Znode。
ZK的每个Znode都会对应一个叫作Stat的数据结构,而Stat记录了version当前的Znode的版本、
cversion当前Znode子节点的版本和aversion当前Znode的ACL版本共当前的3个数据版本。
Zookeeper将Znode数据保存在内存中,这是实现高吞吐量和低延迟性能的原因;同时将这些数据以操作日志和快照的形式持久化到磁盘上,以免进程重启时数据丢失
Znode的特点:
一次写入、多次读取,数据写入后不可更改。
可以存储多个版本的数据,以实现更新顺序性。
一次性读取整个Znode,不支持部分读取。
Znode类型
PERSISTENT持久化目录节点。客户端与zookeeper断开连接后,该节点依旧存在
PERSISTENT_SEQUENTIAL持久化顺序编号目录节点。客户端与zookeeper断开连接后,该节点依旧存在,只是Zookeeper给该节点名称进行顺序编号
EPHEMERAL临时目录节点。客户端与zookeeper断开连接后,该节点被删除
EPHEMERAL_SEQUENTIAL临时顺序编号目录节点。客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号
 
CONTAINER容器类型节点,主要用于zk的leader选举和分布式锁等使用场景,其特点是当容器节
点的最后一个子节点被删除,则该节点会变成候选删除节点。在容器zNode内创建child时,应该随
时准备catch KeeperException.NoNodeException,因为容器znode随时可能被server删除,并在
发生KeeperException.NoNodeException 时重新创建容器znode。
PERSISTENT_WITH_TTL是带过期时间的永久节点,一旦在过期时间内节点没有任何修改,并且没
有任何子节点,则该节点会被删除。TTL时间单位为毫秒。如果znode没有在TTL中修改,并且没有
子节点,该容器znode将被server自动删除。2.7.2.1.3 监听通知机制
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)
时,zookeeper会通知客户端。一次监听事件只会被触发一次,如果想要监听到znode的第二次变更,
需要重新注册监听。
客户端可以通过watch机制关注Znode的信息变化,实现配置管理、数据同步和分布式锁等功能。客户端首先需要注册一个watch来观察某个Znode。当出现数据更新或被删除、子节点发生变化等情况时,Zookeeper集群会通过异步消息向客户端发送事件通知。通知发送后,该watcher就会失效,如果此时再发送信息变化,客户端就无法获取新的通知,除非客户端在进行新的注册。可见watch机制能够确保消息的顺序性(旧消息被接收之前,客户端无法获得新消息)以及最终一致性,但无法确保所有的数据变化都能够被观察到。
 
因为ZK有watch机制,可以随时发现一些数据的变化,从而达到数据的及时性。
ZK的所有读操作都可以设置watch监视点: getData, getChildren, exists. 写操作则是不能设置监视
点的监视有两种类型:数据监视点和子节点监视点。创建、删除或者设置znode都会触发这些监视点。exists,getData 可以设置监视点。getChildren 可以设置子节点变化
可能监测的事件类型有: NodeCreated、NodeDataChanged、NodeDeleted、
NodeChildrenChanged
ZK 可以做到,只要数据一发生变化,就会通知相应地注册了监听的客户端。那么原理应该是
客户端注册Watcher到服务端
服务端发生数据变更
服务端通知客户端数据变更
客户端回调Watcher处理变更应对逻辑
public ZooKeeper(String connectString, int sessionTimeout, Watcher watcher)
这个Watcher将作为整个ZooKeeper会话期间的默认Watcher,会一直被保存在客户端
ZKWatchManager的defaultWatcher中。另外ZK客户端也可以通过getData、exists 和 getChildren 三个接口来向 ZooKeeper 服务器注册 Watcher
ACL权限控制策略
ZooKeeper采用的是ACL权限控制策略。共有5种权限
CREATE创建子节点的权限
READ获取节点数据和子节点的权限
WRITE更新节点数据的权限
DELETE删除子节点的权限
ADMIN设置节点ACL的权限
ZAB原子消息广播协议
ZAB是一种数据分布式一致性算法,是paxos算法的简化版。ZAB协议中有Leader、Follower和
Observer三种角色。其中所有写请求首先转发到Leader节点上,所有的更新事务只能由这个Leader发起,Leader节点上数据的变更会同步到Follower节点上。Follower负责同步Leader节点的数据,并提供数据查询功能,当Leader节点失效时有权参与投票选举,新的Leader只有在之前事务都被处理后才能发起新的事务。Observer同步Leader节点的数据,并提供数据查询功能,但是没有投票选举,只是用于提高集群的查询性能。

 ZooKeeper的应用
Hadoop在默认情况下并不会使用Zookeeper。具体场景:HDFS和MapReduce采用主从结构,由主节
点进行集群管理,子节点之间不会自主进行协调、同步和监控等。这种结构使得子节点易于横向扩展,但主节点存在单点故障问题,即主节点宕机后,整个集群就失效了。Hadoop可以通过Zookeeper的协调能力实现主节点的高可用性,来解决这一个问题。
HBase中自带Zookeeper服务,但也可以禁用后选择外部独立安装的Zookeeper为其提供服务。HBase利用ZK实现Regionserver监控、多Master高可用性管理以及META表入口存储等功能。