午夜时分程序猿惨遭领导叫到小黑屋！既然是……Zookeeper干货

概述：

Zookeeper(zk是一个分布式协凋服务的开源框架，可以用于实现分布式系统中常见的发布/订阅、负载均衡、命令服务、分布式协凋/通知、集群管理、 Master选举、分布式锁和分布式队列等功能。主要用来解决分布式集群中应用系统的一致性间题。也可以理解为一个文件系统+监听机制很多框架依赖协助管理

本质：

ZooKeeper本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。ZK集群是一个标准的主从集群

特性：

可靠性：如果消息被其中一台服务器接收，那么将被整个服务器接收。

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

实时性：一旦一个事务被成功应用后，ZooKeeper可以保证客户端立即可以读取到这个事务变更后的最新状态数据。

数字更新原子性：所有事务请求的处理结果在整个集群中所有的机器上都是一致的；一次数据更新要么成功（半数节点以上成功），要么成功要么失败，不存在中间状态！

（划重点）全局一致性：zk集群中任何一个节点都会保存一份相同的数据，客户端可以连接到任何一台机器上去，所有的客户端看到的服务端数据模型都是一致的；这是最重要的特性

全局一致性

ZK集群角色：

zk集群角色

主角色：(leader)：

事务性请求的唯一处理和调庋者全局统一协调管理各个 follower,负责进行投票的发起和决议，更新系统状态

从角色：(follower):

响应非事务处请求转发事务性请求给 leader并向客户端返回结果，在选主过程中参与投票

观察者：(Observer):

可以连接客户端，将写请求转发给 leader,但不参加投票过程，只同步 sleader的状态目的是为了扩展系统，提高读取速度

客户端：( client )请求发起方

zk数据模型：

在结构上和标准文件系统一样都是所谓的目录树结构

在目录树中节点统称为 znode兼具文件夹和文件两种特点

节点路径都是从\根目录开始路径唯一性

节点 Znode可以包含数据和子节点，但是短暂的ephemera类型的节点不能有子节点

znode存储文件大小有限制通常不超过1M

节点不支持部分读写，而是一次性完整读写

客户端应用可以在节点上设置监视器

zk的节点：

Znode有两种类型,短暂的( ephemera)和持久的( persistent)

Znode的类型在创建时确定并且之后不能再修改

短暂 znode在客户端会话结束时,zk会将其删除,短暂 znode不可以有子节点

持久 znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除

序列化的特性父节点全局维护序列化的编号从0000000自动增加

Zonde的四种目录节点形式：

PERSISTENT:永久节点

EPHEMERAL:临时节点

PERS| STENT SEQUENTIAL:永久节点、序列化

EPHEMERAL SEQUENTIAL:临时节点、序列化

zk的she命令行操作:

创建节点

create [-s][-e] path data acl

s或-e分别指定节点特性,顺序或临时节点,若不指定,则表示持久节点;acl用来进行权限控制。

查看节点

Is path(可以列出 Zookeeper指定节点下的所有子节点,只能查看指定节点下的第一级的所有子节点

get path(可以获取 Zookeeper指定节点的数据内容和属性信息)

修改节点数据

set path newdata[ dataversion版本]通常不指定由其自动维护数据变化就+1

删除节点

delete path [version]

rmr path有子节点的路径

对节点的子节点个数和数据长度开启限制

首先必须该节点已经存在

限制为软性限制如果超出只会在日志中默默警告一下

setquota设置限制 listquota显示限制 delquota删除限制

setquota -n|-b val path

(n:子节点最大长度b:数据值最大长度val:子节点最大个数或数据值的最大长度path节点路径)

zk的监听机制:

客户端向服务端注册 Watcher(设置监听)、服务端事件发生触发 Watcher(监听的执行)、客户端回调 Watcher得到触发事件情况(触发监听从而每个客户端都很快知道它所关注的目录节点的状态发生变化,而做出相应的反应回调 callback)是 Zookeeper实现分布式协调服务的重要特性

zk的监听机制特点

监听先注册才能触发

次性触发第一次有用

event异步发送 watcher的通知事件从服务端发送到客户端是异步的。

客户端可以去监听zk目录树几种事件发生:节点创建节点删除节点数据改变子节点改变

zk中的监听分为两大类:

第一类叫做系统自带的监听不需要注册自动满足条件触发type= None, path=null  用户需要就处理不需要就忽略不计

第二类叫做用户自定义的监听必须满足先注册再触发一次性触发

顺序访问:

对于来自客户端的每个更新请求,Zookeeper都会分配个全局唯一的递增ID,这个ID反映了所有事务请求的先后顺序

高性能高可用:

ZooKeeper将数据存全量储在内存中以保持高性能,并通过服务集群来实现高可用,由于Zookeeper的所有更新和删除都是基于事务的,所以其在读多写少的应用场景中有着很高的性能表现。

zookeeper选举机制：

zk选举机制

Zookeeper的典型应用场景

数据的发布/订阅:

Zookeeper i过 Watcher机制可以实现数据的发布和订阅。分布式系统的所有的服务节点可以对某个 ZNode注册监听,之后只需要将新的配置写入该 ZNode,所有服务节点都会收到该事件。

命名服务:

在分布式系统中,通常需要一个全局唯一的名字,如生成全局唯的订单号等, Zookeeper可以通过顺序节点的特性来生成全局唯一1D,从而可以对分布式系统提供命名服务。

Master选举:

分布式系统一个重要的模式就是主从模式 Master/Salves), Zookeeper可以用于该模式下的Matser选举。可以让所有服务节点去竟争性地创建同一个 ZNode,由于 Zookeeper不能有路径相同的 ZNode,必然只有一个服务节点能够创建成功,这样该服务节点就可以成为 Master节点。

分布式锁:

可以通过 Zookeeper的临时节点和 Watcher机制来实现分布式锁

锁的释放情况有以下两种:

当正常执行完业务逻辑后,客户端主动将临时 ZNode删除,此时锁被释放

当获得锁的客户端发生宕机时,临时 ZNode会被自动删除,此时认为锁已经释放。

集群管理:

Zookeeper还能解决大多数分布式系统中的问题

可以通过创建临时节点来建立心跳检测机制

分布式系统的某个服务节点宕机,则会话会超时,此时该临时节点会被删除,相应的监听事件就会被触发

分布式系统的每个服务节点还可以将自己的节点状态写入临时节点,从而完成状态报告或节点工作进度汇报

通过数据的订阅和发布功能, Zookeeper还能对分布式系统进行模块的解耦和任务的调度。

通过监听机制,还能对分布式系统的服务节点进行动态上下线,从而实现服务的动态扩容。

ACL:

Zookeeper采用AcL( Access Control lists)策略来进行权限控制定义了五种权限: CREATE:允许创建子节点

READ:允许从节点获取数据并列出其子节点

如果觉得对你有所帮助。记得收藏和关注呦！（每日更新各种框架）

如需转载请注明出处（创作不易请见谅）

和巨婴程序猿一起成长。让自己变的更优秀