zookeeper框架——基本介绍

打个广告，帮朋友卖点东西，东西超便宜的哟【衣服鞋子等】，厂家直接出货，绝对低于市场价！！！ 一般都比市场价便宜3—7折【都是牌子货】，如果您感兴趣，可以扫描屏幕下方的二维码，感谢关注！！！

---

一、基本介绍

        Zookeeper 是 Google 的 Chubby一个开源的实现，是 Hadoop 的分布式协调服务 。它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。

        大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等） ，目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制，协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器。而ZooKeeper提供通用的分布式锁服务，用以协调分布式应用。zookeeper的最主要功能就是保管客户端提交的数据（极其少量的数据），每一份数据在zookeeper叫做一个znode。znode之间形成一种树状结构（类似于文件树）。虽然说可以提供各种服务，但是zookeeper在底层其实只提供了两个功能：

• 管理(存储，读取)用户程序提交的数据；
• 并为用户程序提供数据节点监听服务；

二、工作原理

        Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。 一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。

        广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态(只要集群中有半数以上节点存活，集群就能提供服务)。 

三、应用场景

1、统一命名服务

        分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，既对人友好又不会重复。 Name Service 是 Zookeeper 内置的功能，只要调用 Zookeeper 的 API 就能实现。【其实就类似Doubbo和Spring Cloud的注册中心，将服务Id和对应的服务地址放到Zookeeper中】

2、配置管理

        配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 PC Server 运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的 PC Server，这样非常麻烦而且容易出错。

        将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。【solrCloud就是将配置文件（主要是schema.xml、solrconfig.xml）都交由zookeeper统一管理的】

3、集群管理

        Zookeeper 能够很容易的实现集群管理的功能，如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。

        Zookeeper 不仅能够维护当前的集群中机器的服务状态，而且能够选出一个“总管”，让这个总管来管理集群，这就是 Zookeeper 的另一个功能 Leader Election。

四、zookeeper结构和命令

1、 zookeeper结构

        zookeeper的数据结构为层次化的目录结构，命名符合常规文件系统规范。每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识。节点Znode可以包含数据和子节点（但是EPHEMERAL类型的节点不能有子节点，下一页详细讲解）。客户端应用可以在节点上设置监视器。

其中Znode有两种类型：

• 短暂（ephemeral）（断开连接自己删除）
• 持久（persistent）（断开连接不删除）

有四种形式的目录节点（默认是persistent ）：

• PERSISTENT
• PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ）
• EPHEMERAL
• EPHEMERAL_SEQUENTIAL

在创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序。

2、zookeeper命令行操作

        可以通过bin命令下的zkCli.sh（运行 zkCli.sh –server <ip>进入命令行工具）启动客户端，启动完成后可以通过help参考基本命令：

1、使用 ls 命令来查看当前 ZooKeeper 中所包含的内容：

[zk: 202.115.36.251:2181(CONNECTED) 1] ls /

2、创建一个新的 znode ，使用 create /zk myData 。这个命令创建了一个新的 znode 节点“ zk ”以及与它关联的字符串：

[zk: 202.115.36.251:2181(CONNECTED) 2] create /zk "myData“

3、我们运行 get 命令来确认 znode 是否包含我们所创建的字符串：

[zk: 202.115.36.251:2181(CONNECTED) 3] get /zk
#监听这个节点的变化,当另外一个客户端改变/zk时,它会打出下面的
#WATCHER::
#WatchedEvent state:SyncConnected type:NodeDataChanged path:/zk
[zk: localhost:2181(CONNECTED) 4] get /zk watch

4、下面我们通过 set 命令来对 zk 所关联的字符串进行设置：

[zk: 202.115.36.251:2181(CONNECTED) 4] set /zk "zsl"

5、下面我们将刚才创建的 znode 删除：

[zk: 202.115.36.251:2181(CONNECTED) 5] delete /zk

6、删除节点：rmr

[zk: 202.115.36.251:2181(CONNECTED) 5] rmr /zk

3、通过命令方式演示zookeeper的监听

        首先我们使用启动两个zookeeper客户端（如果启动时不指定ip:port，默认连接本地），启动客户端1：

然后启动客户端2，启动命令一样，启动后使用命令连接的和客户端1相同的zookeeper节点，如下：

然后先在客户端1创建文件结点，

然后在客户端2上查看：

这时，我们在客户端1上set值时，客户端2上是不会收到通知的，除非我们

即表示启动监听，这时我们在客户端1上更改值，

我们再来看客户端2：

我们发现会收到监听事件，但是当我们再在客户端1上改变值时，将不会再监听到（一次性的），需要再次启动监听。