ZooKeeper因其使用方便、性能优异、稳定性好等特点,被广泛应用于Hadoop、HBase、Kafka、Dubbo等大型分布式系统中。本文主要介绍了史上最便捷的构建Zookeeper服务器的方法。有需要的朋友可以参考一下。
什么是动物园管理员
ZooKeeper是Apache的顶层项目,为分布式应用提供高效、高可用的分布式协调服务,提供数据发布/订阅、负载均衡、命名服务、分布式协调/通知、分布式锁定等分布式基础服务。ZooKeeper因其使用方便、性能优异、稳定性好等特点,被广泛应用于Hadoop、HBase、Kafka、Dubbo等大型分布式系统中。
Zookeeper有三种 *** 作模式:单机模式、伪集群模式和集群模式。
关于动物园管理员的知识
动物园管理员的数据模型
动物园管理员的节点属性
ZooKeeper节点具有生命周期,这取决于节点的类型。在ZooKeeper中,节点根据持续时间可以分为持久节点(PERSISTENT)和临时节点(emersely),根据是否有序可以分为顺序节点(SEQUENTIAL)和无序节点(unordered)。
一旦创建了持久节点,它将一直保存在Zookeeper中,除非它被主动删除(它不会消失,因为创建该节点的客户端的会话是无效的)。临时节点
动物园管理员的应用场景
ZooKeeper是一个高度可用的分布式数据管理和系统协调框架。这个框架基于Paxos算法的实现,保证了分布式环境下数据的强一致性,也正是因为这个特性,ZooKeeper解决了很多分布式问题。
值得注意的是,ZooKeeper并不是天生为这些应用场景而设计的,而是很多开发者后来根据其特点,利用其框架提供的一系列API接口(或原语集)摸索出来的典型使用方法。
数据发布和订阅(配置中心)
发布-订阅模式,所谓配置中心,顾名思义就是发布者将数据发布到ZK节点,供订阅者动态获取数据,从而实现配置信息的集中管理和动态更新。比如全局配置信息、面向服务的服务框架的服务地址列表等。非常适合使用。
应用程序中使用的一些配置信息放在ZK上进行集中管理。这种场景通常是这样的:应用启动时会主动获取一次配置,同时在节点上注册一个Watcher,这样以后每次更新配置时都会实时通知订阅的客户端,总是能达到获取最新配置信息的目的。在分布式搜索服务中,索引的元信息和服务器集群机器的节点状态存储在ZK的一些指定节点上,每个客户端都可以订阅这些信息。分布式日志收集系统。该系统的核心工作是收集分布在不同机器上的日志。采集器通常根据应用来分配采集任务单元,所以需要在ZK上创建一个以应用名为路径的节点P,将该应用的所有机器IP以子节点的形式注册在节点P上,这样当机器发生变化时,可以通知采集器实时调整任务分配。系统中的一些信息需要动态获取,手动修改这些信息会有问题。通常是公开接口,比如JMX接口,以获得一些运行时信息。引入ZK后,不需要自己实施一套方案,只需要将信息存储在指定的ZK节点上即可。注意:在上面提到的应用场景中,有一个默认的前提:数据量小,但数据更新可能更快。
负载平衡
这里的负载均衡指的是软负载均衡。在分布式环境中,为了保证高可用性,通常同一个应用程序或同一个服务提供商会部署多个副本来实现对等服务。但是,消费者需要在这些对等服务器中选择一个来执行相关的业务逻辑,其中消息中间件中的生产者是典型的,消费者的负载是均衡的。
命名服务
命名服务也是分布式系统中的常见场景。在分布式系统中,通过使用命名服务,客户端应用程序可以根据指定的名称获取信息,如资源或服务的地址和提供者。命名实体通常可以是集群中的机器、提供的服务地址、远程对象等等——所有这些都可以统称为名称。其中最常见的是一些分布式服务框架中的服务地址列表。通过调用ZK提供的用于创建节点的API,可以很容易地创建一个全局唯一的路径,该路径可以用作名称。
阿里巴巴的开源分布式服务框架Dubbo使用ZooKeeper作为其命名服务,以维护全球服务地址列表。在Dubbo实现中:服务提供者启动时,将其URL地址写入ZK上指定的node/Dubbo/${servicename}/providers目录,此 *** 作完成服务发布。当服务消费者启动时,在目录/dubbo/${servicename}/providers中订阅提供者的URL地址,并在目录/dubbo/${servicename}/consumers中写入他们自己的URL地址。注意,所有在ZK上注册的地址都是临时节点,这样服务提供者和消费者可以自动感知资源的变化。
此外,Dubbo还通过订阅/dubbo/${serviceName}目录中所有提供者和消费者的信息来监控服务粒度。
分布式通知/协调
ZooKeeper中独特的watcher注册和异步通知机制可以很好地实现分布式环境中不同系统之间的通知和协调,实现数据变化的实时处理。方法通常是不同的系统在ZK上注册同一个znode,并监控znode的变化(包括znode本身及其子节点的内容)。如果一个系统更新了znode,另一个系统可以收到通知并做出相应的处理。
另一种心跳检测机制:检测系统和被检测系统不是直接关联,而是通过zk上的一个节点关联,大大降低了系统耦合性。另一种系统调度模式:一个系统由控制台和推送系统组成,控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台所做的一些 *** 作,实际上是修改了ZK上一些节点的状态,ZK将这些变化通知给注册Watcher的客户端,也就是推送系统,于是他们做出相应的推送任务。
另一种工作汇报模式:有些类似于任务分配系统。子任务开始后,在zk中注册一个临时节点,定期汇报自己的进度(把进度写回临时节点),让任务管理者实时了解任务进度。
分布式锁
分布式锁,这主要是因为ZooKeeper为我们保证的数据的强一致性。服务可以分为两类,一类是保持排他性,一类是控制时机。
所谓垄断,就是所有试图获取这个锁的客户端只能成功获取这个锁。通常的做法是把zk上的一个znode看成一个锁,通过创建ZnOde来实现。所有客户机都创建/distribute_lock节点,成功创建的客户机最终拥有这个锁。控制计时,即所有查看该锁的客户机,最终将被调度执行,但是有一个全局计时。做法基本和上面类似,只是这里/distribute_lock已经提前存在,客户端在它下面创建一个临时有序节点(这个可以通过节点的属性控件来指定:createmode.periodic_sequential)。Zk的父节点(/distribute_lock)维护一个序列,这个序列保证了子节点的创建时序,从而形成了每个客户端的全局时序。
由于同一节点下的子节点名称不能相同,只要在某个节点下创建了一个znode,创建成功就意味着锁定成功。注册监听器监听这个znode,只要删除这个znode就通知其他客户端锁定。创建临时顺序节点:在某个节点下创建一个节点,请求到来时创建一个节点。因为是顺序的,所以最小的序列号获得锁,当锁被释放时,通知下一个序列号获得锁。
分布式队列
队列方面,简单来说有两种,一种是常规的先入先出队列,一种是等待队列成员集合后再按顺序执行。对于第一种队列,基本原理和上面提到的分布式锁服务中控制计时的场景是一样的,这里不再赘述。
第二个队列实际上是FIFO队列的增强。通常可以在/queue的znode下预先设置一个/queue/num节点,赋给n(或者直接赋给/queue),表示队列大小。然后,每次队列成员加入时,都会确定是否已经达到队列大小,以及是否可以开始执行。这种用法的典型场景是,在分布式环境中,一个大任务任务A需要完成许多子任务(或者条件准备好了)才能执行。此时,每当一个子任务完成(就绪),就转到/taskList设置自己的临时顺序节点(创建模式。短暂_连续)。当/taskList发现它下面的子节点数量达到指定数量时,它可以按顺序进行下一步。
使用dokcer-compose构建一个集群
上面已经介绍了这么多关于ZooKeeper的应用场景,那么接下来我们就先来学习如何搭建一个ZooKeeper集群,然后实践上面的应用场景。
该文件的目录结构如下:
├──docker-compose.yml
编写docker-compose.yml文件。
docker-compose.yml文件的内容如下:
version:'3.4' services: zoo1: image:zookeeper restart:always hostname:zoo1 ports: -2181:2181 environment: ZOO_MY_ID:1 ZOO_SERVERS:server.1=0.0.0.0:2888:3888;2181server.2=zoo2:2888:3888;2181server.3=zoo3:2888:3888;2181 zoo2: image:zookeeper restart:always hostname:zoo2 ports: -2182:2181 environment: ZOO_MY_ID:2 ZOO_SERVERS:server.1=zoo1:2888:3888;2181server.2=0.0.0.0:2888:3888;2181server.3=zoo3:2888:3888;2181 zoo3: image:zookeeper restart:always hostname:zoo3 ports: -2183:2181 environment: ZOO_MY_ID:3 ZOO_SERVERS:server.1=zoo1:2888:3888;2181server.2=zoo2:2888:3888;2181server.3=0.0.0.0:2888:3888;2181在这个配置文件中,docker运行三个zookeeper映像,它们通过ports字段将本地端口2181、2182和2183绑定到相应的容器端口2181。
ZOO_MY_ID和ZOO_SERVERS是构建Zookeeper集群所需的两个环境变量。ZOO_MY_ID标识服务的ID。它是1到255之间的整数,并且在群集中必须是唯一的。ZOO_SERVERS是集群中主机的列表。
在docker-compose.yml所在的目录下执行docker-composeup,可以看到启动日志。
连接动物园管理员
集群启动后,我们可以连接ZooKeeper在其上执行与节点相关的 *** 作。
首先,我们需要下载ZooKeeper。动物园管理员下载地址。将其解压缩到它的conf目录中,并更改zoo_sample。cfg到zoo.cfg
简介描述
#Thenumberofmillisecondsofeachtick #tickTime:CS通信心跳数 #Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个tickTime时间就会发送一个心跳。tickTime以毫秒为单位。 tickTime=2000 #Thenumberofticksthattheinitial #synchronizationphasecantake #initLimit:LF初始通信时限 #集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数(tickTime的数量)。 initLimit=5 #Thenumberofticksthatcanpassbetween #sendingarequestandgettinganacknowledgement #syncLimit:LF同步通信时限 #集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数(tickTime的数量)。 syncLimit=2 #thedirectorywherethesnapshotisstored. #donotuse/tmpforstorage,/tmphereisjust #examplesakes. #dataDir:数据文件目录 #Zookeeper保存数据的目录,默认情况下,Zookeeper将写数据的日志文件也保存在这个目录里。 dataDir=/data/soft/zookeeper-3.4.12/data #dataLogDir:日志文件目录 #Zookeeper保存日志文件的目录。 dataLogDir=/data/soft/zookeeper-3.4.12/logs #theportatwhichtheclientswillconnect #clientPort:客户端连接端口 #客户端连接Zookeeper服务器的端口,Zookeeper会监听这个端口,接受客户端的访问请求。 clientPort=2181 #themaximumnumberofclientconnections. #increasethisifyouneedtohandlemoreclients #maxClientCnxns=60 # #Besuretoreadthemaintenancesectionofthe #administratorguidebeforeturningonautopurge. # #http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance # #ThenumberofsnapshotstoretainindataDir #autopurge.snapRetainCount=3 #Purgetaskintervalinhours #Setto"0"todisableautopurgefeature #autopurge.purgeInterval=1 #服务器名称与地址:集群信息(服务器编号,服务器地址,LF通信端口,选举端口) #这个配置项的书写格式比较特殊,规则如下: #server.N=YYY:A:B #其中N表示服务器编号,YYY表示服务器的IP地址,A为LF通信端口,表示该服务器与集群中的leader交换的信息的端口。B为选举端口,表示选举新leader时服务器间相互通信的端口(当leader挂掉时,其余服务器会相互通信,选择出新的leader)。一般来说,集群中每个服务器的A端口都是一样,每个服务器的B端口也是一样。但是当所采用的为伪集群时,IP地址都一样,只能时A端口和B端口不一样。可以不修改zoo.cfg,只是默认配置,然后在解压后的bin目录下执行命令。/zkCli.sh-server127.0.0.1:2181进行连接。
欢迎来到动物园管理员!
2020-06-0115:03:52,512[myid:]-INFO[main-sendthread(localhost:2181):clientcnxn$sendthread@1025]-打开与服务器localhost/127.0.0.1:2181的套接字连接。将不尝试使用SASL进行身份验证(未知错误)
JLine支持已启用
2020-06-0115:03:52,576[myid:]-INFO[main-sendthread(localhost:2181):clientcnxn$sendthread@879]-套接字连接已建立到localhost/127.0.0.1:2181,正在启动会话
279
观察者::
WatchedEvent状态:SyncConnected类型:None路径:null
[ZK:127.0.0.1:2181(CONNECTED)0]
接下来,我们可以使用命令来查看节点。
使用ls命令查看当前ZooKeeper中包含的内容。
命令:ls/
[zk:127.0.0.1:2181(已连接)10]ls/
[动物园管理员]
创建了新的znode节点“zk”及其关联的字符串。
命令:create/zkmyData
[zk:127.0.0.1:2181(已连接)11]创建/zk我的数据
Created/zk[zk:127.0.0.1:2181(已连接)12]ls/[zk,zookeeper][zk:127.0.0.1:2181(已连接)13]`''
获取znode节点zk
命令:get/zk
[zk:127.0.0.1:2181(已连接)13]get/zk
mydataczxid=0x4000000008ctime=MonJun0115:07:50CST2020mZxid=0x400000008mtime=MonJun0115:07:50CST2020pZxid=0x400000008cversion=0dataversion=0ACLversion=0ephemeralowner=0x0dataLength=6numChildren=0
```
删除节点zk
命令:delete/zk
[zk:127.0.0.1:2181(已连接)14]删除/zk
[zk:127.0.0.1:2181(已连接)15]ls/[动物园管理员]`''
由于篇幅有限,下一篇文章将根据上面提到的ZooKeeper应用场景,用代码逐一实现。
动物园管理员的Docker档案库
动物园管理员的Docker档案库
动物园管理员的Docker档案库
可以直接从上面拉项目,启动RocketMQ只需要两步。
从GitHub中提取项目,并在ZooKeeper文件夹中执行docker-composeup命令
参考文章
http://www.jucaiylzc.cn/2011/10/08/1232/
http://www.Dongdongrji.cn/2019/04/25/1_Zookeeper%E8%AF%A6%E8%A7%A3/
https://www.jintianxuesha.com/cyfonly/p/5626532.html
http://www.hengxuangyul.comcom/docker-zookeeper-cluster/
https://www.qiaoheibpt.com·maizitoday.github.io/post/zookeeper%E5%85%A5%E9%97%A8/
摘要
这就是这篇关于史上最便捷的构建Zookeeper服务器的文章。有关构建Zookeeper服务器的更多信息,请搜索我们以前的文章或继续浏览下面的相关文章。希望大家以后能多多支持我们!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)