Zookeeper知识汇总

简介

概念

Zookeeper是一个开源的分布式协调服务,它的设计目标是将那些复杂切容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用

原语:操作系统或计算机网络用语范畴,是由若干条指令组成的,用语完成一定功能的一个过程.具有不可分割性即原语的执行必须是连续的,在执行过程中不允许被中断

zk为我们提供了高可用,高性能,稳定的分布式数据一致性方案,通常被用语实现诸如数据发布/订阅,负载均衡,命名服务,分布式协调/通知,集群管理,master选举,分布式锁,分布式队列等功能

特点

顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。

原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。

单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。

可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

应用场景

典型场景

1. 分布式锁:通过创建唯一节点获得分布式锁,当获得锁的以防执行完代码或是挂掉之后就释放锁
2. 命名服务,可以通过zk的顺序节点生成唯一id
3. 数据发布/订阅,通过watcher机制可以很方便的实现数据发布/订阅.当你数据发布到了zk被监听的节点上,其他机器可以通过zk上节点的变化来实现配置的动态更新

ZK的重要概念

Data model(数据模型)

zk数据模型采用层级化的多叉树结构,每个节点上都可以存储数据,这些数据可以是数字,字符串或者是二级序列.并且每个节点还可以拥有N个子节点,最上层根节点以/来代表每个数据节点在Zookeeper中被称为znode,它是zookeeper中数据的最小单元.并且每个znode都是一个唯一路径标识

zookeeper是用来协调服务的,而不是来存储业务数据的,所以不要放比较大的数据在znode上,zk给出每个节点的数据大小是1M

从下图可以更直观看出,zk节点路径标识方式和unix文件系统路径十分相似,都是用斜杠进行分割路径标识,开发人员可以向这个节点中写入数据,也可以在节点下面创建子节点

Znode

我们知道每个数据节点在Zookeeper中被称为znode,它是Zokeeper中数据的最小单元.你要存放的数据就放在上面

通常是将znode分为

• 持久节点:一旦创建就一直存在,直到删除
• 临时节点,临时节点的生命周期是与客户端会话session绑定的,会话消失则节点消失,并且,临时节点只能做叶子节点,不能创建子节点
• 持久顺序节点:除了具有持久节点的特性以外,子节点的名称还具有顺序性。比如 /node1/app0000000001 、/node1/app0000000002 。
• 临时顺序:除了具备临时节点的特性外,子节点名称还具有顺序性.他们相对于上面俩种的特性是,zk会自动在这俩种节点之后增加一个数字后缀,而路径+数字后缀是能保证唯一的
• 容器节点,当容器中没有任何子节点,该容器会被zk定期清除
• 持久TTL节点:当节点下面没有子节点的话,超过了TTL设定的时间后,就会被自动删除(持久顺序TTL同理)

数据结构

• data:节点存放的数据具体内容

• stat:状态信息,描述当前znode的元数据 ,记录了znode的三个相关版本

  • dataversion:当前znode节点的版本号
  • cversion:当前znode子节点的版本
  • aclVersion,当前znode的acl版本

• acl:权限,定义了什么样的用户能够操作这个节点,并且能够进行怎样的操作

  • c:create 创建权限
  • w: write更新权限
  • r:read读取权限
  • d:delete:删除权限
  • a:admin管理者权限,允许对该节点进行acl权限设置
• child:当前节点的子节点

watcher事件监听器

watcher事件监听器是zk中一个很重要的特性.zk允许用户在指定节点上注册一些watcher,并且在一些特定事件触发的时候,zookeeper服务端会将事件通知感兴趣的客户端挂上去,该机制是zookeeper实现分布式协调服务的重要特性

非常有用的特性,zookeeper基本离不开watcher(事件监听)机制

会话session

session可以看做是zk服务器与客户端之间的一个tcp长连接,通过这个连接,客户端能够通过心跳检测与服务器保持有效会话,也能够向zk服务器发送请求并接收响应,同时还能够通过该连接来接收来自服务器的watcher事件通知

Session 有一个属性叫做：sessionTimeout ，sessionTimeout 代表会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

另外，在为客户端创建会话之前，服务端首先会为每个客户端都分配一个 sessionID。由于 sessionID是 ZooKeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

ZK集群

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程 来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

俩种基本模式分布式

崩溃恢复:当整个服务框架在启动的过程中,或是当leader服务器出现网络中断,崩溃退出与重启等异常情况时,ZAB协议就回家进入恢复模式并选举产生新的leader服务器.当选举产生了新的leader服务器,同时集群中已经有过半的机器与该leader服务器完成了状态同步后,ZAB协议就会退出恢复模式.其中,所谓的状态同步就是数据同步,用来保证集群中存在过半的机器能够和leader服务器的数据状态保持一致

消息广播当集群中已经有过半的follower服务器完成了和leader服务器的状态同步,那么这个服务框架就可以进入消息广播模式了.当一台同样遵守ZAB协议服务器启动后加入到集群中时,如果此集群中已经存在一个leader服务器在负责进行消息广播,那么新加入的服务器就会自觉地进入数据恢复模式:找到leader所在服务器,并与其进行数据同步,然后一起参与到消息广播流程中去