Zookeeper

Dubbo 阿里框架 

ZooKeeper顾名思意:动物园管理员 

  它是拿来管大象(Hadoop)、蜜蜂(Hive)、小猪(Pig)的管理员, Apache Hbase和Apache Solr以及阿里的Dubbo等项目中都采用到了Zookeeper 。

   一句话:ZooKeeper是一个分布式协调技术、高性能的,开源的分布式系统的协调(Coordination)服务 ,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。 它是一个为分布式应用程序一致性和分布式协调技术服务的软件。

设计模式来理解:

是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,

然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在

Zookeeper上注册的那些观察者做出相应的反应,从而实现集群中类似Master/Slave管理模式

zookeeper=类似unix文件系统+通知机制+Znode节点

作用:服务注册+分布式系统的一致性通知协调

统一命名服务(Name Service如Dubbo服务注册中心)

  

Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,是阿里巴巴SOA服务化治理方案的核心框架,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点。 

  

在Dubbo实现中: 

  

服务提供者在启动的时候,向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址, 

这个操作就完成了服务的发布。 

服务消费者启动的时候,订阅/dubbo/${serviceName}/providers目录下的提供者URL地址, 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。 

  

注意,所有向ZK上注册的地址都是临时节点,这样就能够保证服务提供者和消费者能够自动感应资源的变化。 另外,Dubbo还有针对服务粒度的监控,方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。

配置管理(Configuration Management如淘宝开源配置管理框架Diamond)

  在大型的分布式系统中,为了服务海量的请求,同一个应用常常需要多个实例。如果存在配置更新的需求,常常需要逐台更新,给运维增加了很大的负担同时带来一定的风险(配置会存在不一致的窗口期,或者个别节点忘记更新)。zookeeper可以用来做集中的配置管理,存储在zookeeper集群中的配置,如果发生变更会主动推送到连接配置中心的应用节点, 实现一处更新处处更新的效果 

  现在把这些配置全部放到zookeeper上去,保存在 Zookeeper 的某个目录节点中,然后所有相关应用程序对这个目录节点进行监听,一旦配置信息发生变化,每个应用程序就会收到 Zookeeper 的通知,然后从 Zookeeper 获取新的配置信息应用到系统中就好。

 安装:

官网下载安装包,本次版本zookeeper-3.4.11.tar.gz

https://zookeeper.apache.org/releases.html#download

拷贝进入到/opt目录下并解压

tar -zxvf zookeeper-3.4.11.tar.gz

新建专属zookeeper目录,

mkdir /myzookeeper,

 

随后将上一步解压的zookeeper内容拷贝进/myzookeeper目录内

cp zookeeper-3.4.11.tar.gz /myzookeeper

进入conf文件夹,拷贝zoo_sample.cfg改为zoo.cfg

zoo.cfg

tickTime:

   tickTime:通信心跳数,Zookeeper服务器心跳时间,单位毫秒 

Zookeeper使用的基本时间, 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳,时间单位为毫秒。 

它用于心跳机制,并且设置最小的session超时时间为两倍心跳时间.(session的最小超时时间是2*tickTime。)

 

initLimit 

这个配置项是用来配置Zookeeper接收Follower客户端(这里所说的客户端不是用户链接Zookeeper服务器的客户端,而 是Zookeeper服务器集群中连接到leader的Follower服务器 ,Follower在启动过程中,会从Leader同步所有最新数据,然后确定自己能够对外服务的起始状态。Leader允许Follower在 initLimit 时间内完成这个工作)初始化连接是最长能忍受多少个心跳的时间间隔数。 

   

 当已经超过10个心跳的时间(也就是tickTime)长度后Zookeeper服务器还没有收到客户端返回的信息,那么表明这个客户端连接失败。总的时间长度就是10*2000=20秒

syncLimit:LF同步通信时限 

集群中Leader与Follower之间的最大响应时间单位。 

在运行过程中,Leader负责与ZK集群中所有机器进行通信,例如通过一些心跳检测机制,来检测机器的存活状态 , 假如响应超过syncLimit * tickTime(假设syncLimit=5 ,请求和应答时间长度,最长不能超过多少个tickTime的时间长度,总的时间长度就是5*2000=10秒。),Leader认为Follwer死掉,从服务器列表中删除Follwer。 

 # 在运行过程中,Leader负责与ZK集群中所有机器进行通信,例如通过一些心跳检测机制,来检测机器的存活状态。 

如果L发出心跳包在syncLimit之后,还没有从F那收到响应,那么就认为这个F已经不在线了。   

 dataDir:数据文件目录+数据持久化路径  

保存内存数据库快照信息的位置,如果没有其他说明,更新的事务日志也保存到数据库。

clientPort:客户端连接端口 

监听客户端连接的端口。

启动Zookeeper服务之前需要先安装好Java环境

 /myzookeeper/zookeeper-3.4.9/bin路径下

启动

./zkServer.sh start

关闭

./zkServer.sh stop

在Zookeeper服务器成功启动的前提下,在Linux侧的shell命令端口执行下面的ruok四字命令, 

如果能够显示imok 

表示zk服务器端成功启动。

echo ruok | nc 127.0.0.1 2181

客户端连接

连接:./zkCli.sh 
退出:quit 

查看+获得zookeeper服务器上的数据存储信息

ls /

ls /zookeeper

Zookeeper维护一个类似文件系统的数据结构

所使用的数据模型风格很像文件系统的 目录树结构, 简单来说,有点类似windows中注册表的结构,  

有名称, 

有树节点, 

有Key(键)/Value(值)对的关系, 

可以看做一个树形结构的数据库,分布在不同的机器上做名称管理。 

 初识znode节点

ZooKeeper数据模型的结构与Unix文件系统很类似,整体上可以看作是一棵树,每个节点称做一个ZNode 

很显然zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构,其上的每一个节点,我们称之为"znode",每一个znode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识

数据模型/znode节点深入

Znode的数据模型

1、是什么?

Znode维护了一个stat结构,这个stat包含数据变化的版本号、访问控制列表变化、还有时间戳。版本号和时间戳一起,可让Zookeeper验证缓存和协调更新。每次znode的数据发生了变化,版本号就增加。 

  

例如,无论何时客户端检索数据,它也一起检索数据的版本号。并且当客户端执行更新或删除时,客户端必须提供他正在改变的znode的版本号。如果它提供的版本号和真实的数据版本号不一致,更新将会失败。

2、ZooKeeper的Stat结构体

每次修改ZooKeeper状态都会收到一个zxid形式的时间戳,也就是ZooKeeper事务ID。 

事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid,如果zxid1小于zxid2,那么zxid1在zxid2之前发生。

3、总结

zookeeper内部维护了一套类似UNIX的 树形数据结构 :由znode构成的集合, 

znode的集合又是一个树形结构, 

每一个znode又有很多属性进行描述。  Znode = path + data + Stat

 

znode中的存在类型

znode是由客户端创建的,它和创建它的客户端的内在联系,决定了它的存在性:

    PERSISTENT-持久化节点:创建这个节点的客户端在与zookeeper服务的连接断开后,这个节点也不会被删除(除非您使用API强制删除)。   

    PERSISTENT_SEQUENTIAL-持久化顺序编号节点:当客户端请求创建这个节点A后,zookeeper会根据parent-znode的zxid状态,为这个A节点编写一个全目录唯一的编号(这个编号只会一直增长)。当客户端与zookeeper服务的连接断开后,这个节点也不会被删除。 

    EPHEMERAL-临时目录节点:创建这个节点的客户端在与zookeeper服务的连接断开后,这个节点(还有涉及到的子节点)就会被删除。 

    EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点:当客户端请求创建这个节点A后,zookeeper会根据parent-znode的zxid状态,为这个A节点编写一个全目录唯一的编号(这个编号只会一直增长)。当创建这个节点的客户端与zookeeper服务的连接断开后,这个节点被删除。 

    另外,无论是EPHEMERAL还是EPHEMERAL_SEQUENTIAL节点类型,在zookeeper的client异常终止后,节点也会被删除 

基础命令和Java客户端操作

 

posted @ 2019-08-24 10:55  keepsummer  阅读(270)  评论(0编辑  收藏  举报