首页  

zookeeper知识点整理     所属分类 zookeeper 浏览量 1304
分布式协调

hierarchal(层次)树形 数据结构 类似标准文件系统

high performance(高性能), highly available(高可用性), strictly ordered access(严格有序访问)

用于大型分布式系统 高可用避免出现单点故障  严格有序访问可以让Client实现复杂的同步原语

使用场景
数据发布与订阅  配置管理 命名空间服务 分布式通知/协调 分布式锁 集群管理 选主 群组成员管理


Znode 
四种节点类型 PERSISTEN PERSISTENT_SEQUENTAIL EPHEMERAL EPHEMERAL_SEQUENTAIL

持久节点(persistent)  只能通过调用delete删除
临时节点(ephemeral)   临时节点不允许有子节点  
                     删除时机 
                     创建该节点的客户端崩溃或断开连接
                     主动调用delete删除
   
有序节点(sequential)  创建时,一个序号会被追加到路径后,例如创建路径为task/task-,则最终路径为task/task-1


Session 
Client与ZooKeeper之间的通信,需要创建一个Session
当会话无法与当前连接的服务器继续通信时,客户端可能透明地将会话转移到另一个服务器上
同一个会话提供了顺序保障,即请求先进先出

会话超时设置为时间t

服务端	t	    经过时间t后,服务端接收不到这个会话的任何消息,服务端会声明会话过期
客户端	t/3	    经过t/3时间未收到服务端消息,则主动向服务器发送心跳消息
客户端	2t/3	仍未收到服务端消息,则开始寻找其它的服务器,此时它还有t/3的时间去寻找



Watcher 
Client可以在某个znode上设置一个Watcher,来Watch该znode上的变化
一次性,触发一次就会被取消,如果想继续监听,需要客户端重新设置Watcher。

事务日志和快照
dataDir 数据目录,用于存储快照文件(snapshot)
dataLogDir 事务日志目录,存放事务日志

Zookeeper角色

Leader 负责投票的发起和决议,更新系统状态
Follower
  负责接收处理请求
  选Leader的过程中参与投票

Observer 
  接收客户端的连接,将写请求转发到Leader节点,但不参与投票和选举,仅仅接收投票和选举的结果。
  主要用来扩展系统,提高读取速度。
Client 请求发起方

Server的四种状态
leading  
following 
observing 
looking 当前Server不知道leader是谁,正在搜寻。

API

create /path data
create -e /master "xxx"(-e表示临时节点)
create -s /tasks/task- "xxx"(-s创建有序节点)
delete /path	
exists /path
set /path data
get /path
getChildren /path   返回/path节点的所有子节点列表
ls /path

sync
set acl
get acl



两种运行模式

独立模式(standalone)	即单机模式
仲裁模式(quorum)	即一组集群


特性

顺序一致性:按照客户端发送请求的顺序更新数据。FIFO
原子性:更新要么成功,要么失败,不会出现部分更新。
单一系统映像 :无论客户端连接哪个server,都会看到同一个视图。
可靠性:简单、健壮、高性能,如果消息被到一台服务器接受,那么它将被所有的服务器接受。
时效性:Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新数据,或者服务器失效的信息。
      但由于网络延时等原因,Zookeeper不能保证两个客户端能同时得到刚更新的数据,
      如果需要最新数据,在读数据之前调用sync()
      
   
原理

原子广播 通过Zab协议保证各个Server之间数据的同步
Zab协议有两种模式,分别是恢复模式(选举Leader)和广播模式(同步)
保证事务的顺序一致性 使用递增的事务id号(zxid)来标识事务
所有的提议(proposal)都在被提出的时候加上了zxid
zxid 64位数字,高32位是epoch ,用来标识leader关系是否改变,
每次一个leader被选出来,都会有一个新的epoch,标识当前属于那个leader的统治时期。
低32位用于递增计数。


客户端可以从任意一个ZooKeeper服务器读取数据 保证读性能
写请求Forwarder到Leader ,Leader通过原子广播协议,将请求广播给所有的Follower
Leader收到一半以上的写成功的Ack后,认为写成功,将该写持久化,并告诉客户端写成功了。

WAL(Write-Ahead-Log)
预写日志 更新内存数据 
Snapshot
定期将内存中的目录树 Snapshot,
持久化,加快重启之后的恢复速度 ,如果全部依赖WAL replay 恢复,比较慢

对于同一客户端 所有操作 按顺序执行 FIFO 
全局有序和偏序

全局有序针对服务器端  
偏序针对客户端

更新操作串行执行

上一篇     下一篇
VC拒绝你的真实原因

大数据流处理框架对比

java日志框架简介

十八个让你终生受用的时间管理技巧

过目难忘的诗词50句,总有一句触动你

影响世界的100个经典管理定律