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客户端操作