打个广告,帮朋友卖点东西,东西超便宜的哟【衣服鞋子等】,厂家直接出货,绝对低于市场价!!! 一般都比市场价便宜3—7折【都是牌子货】,如果您感兴趣,可以扫描屏幕下方的二维码,感谢关注!!!
![](https://i-blog.csdnimg.cn/blog_migrate/31a59eeb1c3962749a7743606ee67fc4.jpeg)
一、基本介绍
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上改变值时,将不会再监听到(一次性的),需要再次启动监听。