Zookeeper

zookeeper介绍

• Hadoop系统

• 开源的，高效的，可靠的协同工作系统

• 名字服务器，分布式同步，组服务

• Google内部实现叫Chubby

• 基于Paxos协议

 

zookeeper概述

数据模型

– 命名空间

– 与标准文件系统很相似

– 以 / 为间隔的路径名序列组成

– 只有绝对路径，没有相对路径

每个节点自身的信息

– 数据

– 数据长度

– 创建时间

– 修改时间

具有文件，路径的双重特点

 

zookeeper中的几种基本节点

• Persistent Nodes

　　– 永久有效地节点,除非client显式的删除,否则一直存在

• Ephemeral Nodes

　　– 临时节点,仅在创建该节点client保持连接期间有效,一旦连接丢失,zookeeper会自动删除该节 点

• Sequence Nodes

　　– 顺序节点,client申请创建该节点时,zk会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式queue等特殊功能的关键

监控机制(watch)

– 数据节点上设置

– 客户端被动收到通知

– 各种读请求，如getData()，getChildren()，和exists()

三个关键点

– 一次性监控，触发后，需要重新设置

– 保证先收到事件，再收到数据修改的信息

– 传递性

　　• 如create会触发节点数据监控点，同时也会触发父节点的监控点

　　• 如delete会触发节点数据监控点，同时也会触发父节点的监控点

风险

– 客户端有可能看不到所有数据的变化

– 多个事件的监控，有可能只会触发一次

　　• 一个客户端设置了关于某个数据点exists和getData的监控，则当该数据被删除的时候，只会触发 “文件被删除”的通知。

– 客户端网络中断的过程的无法收到监控的窗口时间，要由模块进行容错设计

数据访问

– 每个节点上的“访问控制链”(ACL, Access Control List)保存了各客户端对于该节点的访问 权限。

– 用一个三元组来定义客户端的访问权限：(scheme:expression, perms)

　　• ip:19.22.0.0/16, READ）表示IP地址以19.22开头的主机有该数据节点的读权限。

一致性保证

– 序列一致性：客户端发送的更新将按序在Zookeeper进行更新

– 原子一致性：更新只能成功或者失败，没有中间状态

– 单系统镜像：无论连接哪台Zookeeper服务器，客户端看到的服务器数据一致

– 可靠性：任何一个更新成功后都会持续生效，直到另一个更新将它覆盖。可靠性有两个关键点: 第 一，当客户端的更新得到成功的返回值时，可以保证更新已经生效，但在某些异常情况下（超时 ，连接失败），客户端无法知道更新是否成功；第二，当更新成功后，不会回滚到以前的状态， 即使是在服务器失效重启之后

– 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据， 如果需要最新数据，应该在读数据之前调用sync()接口