ZooKeeper架构
Posted duan2
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ZooKeeper架构相关的知识,希望对你有一定的参考价值。
ZooKeeper服务器端运行于两种模式下:独立模式(standalone)和仲裁模式(quorum)。独立模式几乎与其术语所描述的一样:有一个单独的服务器,ZooKeeper状态无法复制。在仲裁模式下,具有一组ZooKeeper服务器,我们称为ZooKeeper集合(ZooKeeper ensemble),它们之前可以进行状态的复制,并同时为服务于客户端的请求。从这个角度出发,我们使用术语“ZooKeeper集合”来表示多个服务器设施,这个设施可以由独独模式的一个服务器组成,也可以仲裁模式下的多个服务器组成。
1.1.1 ZooKeeper仲裁
在仲裁模式下,ZooKeeper复制集群中的所有服务器的数据树。但如果让一个客户端等待每个服务器完成数据保存后再继续,延迟问题将无法接受。在公共管理领域,法定人数是指进行一项投票所需的立法者的最小数量。而在ZooKeeper中,则是指为了使ZooKeeper工作必须有效运行的服务器的最小数量。这个数字也是服务器告知客户端安全保存数据前,需要保存客户端数据的服务器的最小个数。例如,我们一共有5个ZooKeeper服务器,但法定个数为3个,这样,只要任何3个服务器保存了数据,客户端就可以继续,而其他两个服务器最终也将捕获到数据,并保存数据。
为了明白这到底是什么意思,让我们先来通过一个例子来看看,如果法定人数太小,会如何出错。假设有5个服务器并设置法定人数为2,现在服务器s 1 和s 2 确认它们需要对一个请求创建的znode/z进行复制,服务返回客户端,指出znode创建完成。现在假设在复制新的znode到其他服务器之前,服务器s 1 和s 2 与其他服务器和客户端发生了长时间的分区隔离,整个服务的状态仍然正常,因为基于我们的假设设定法定人数为2,而现在还有3个服务器,但这3个服务器将无法发现新的znode/z。因此,对创建节点/z的请求是非持久化的。
通过使用多数方案,我们就可以容许f个服务器的崩溃,在这里,f为小于集合中服务器数量的一半。例如,如果有5个服务器,可以容许最多f=2个崩溃。在集合中,服务器的个数并不是必须为奇数,只是使用偶数会使得系统更加脆弱。假设在集合中使用4个服务器,那么多数原则对应的数量为3个服务器。然而,这个系统仅能容许1个服务器崩溃,因为两个服务器崩溃就会导致系统失去多数原则的状态。因此,在4个服务器的情况下,我们仅能容许一个服务器崩溃,而法定人数现在却更大,这意味着对每个请求,我们需要更多的确认操作。底线是我们需要争取奇数个服务器
1.1.2会话
在对ZooKeeper集合执行任何请求前,一个客户端必须先与服务建立会话。会话的概念非常重要,对ZooKeeper的运行也非常关键。客户端提交给ZooKeeper的所有操作均关联在一个会话上。当一个会话因某种原因而中止时,在这个会话期间创建的临时节点将会消失。
当客户端通过某一个特定语言套件来创建一个ZooKeeper句柄时,它就会通过服务建立一个会话。客户端初始连接到集合中某一个服务器或一个独立的服务器。客户端通过TCP协议与服务器进行连接并通信,但当会话无法与当前连接的服务器继续通信时,会话就可能转移到另一个服务器上。ZooKeeper客户端库透明地转移一个会话到不同的服务器
1.1.3开始使用ZooKeeper
开始之前,需要下载ZooKeeper发行包。ZooKeeper作为Apache项目托管到http://zookeeper.apache.org。通过下载链接,你会下载到一个名字类似zookeepe-3.4.5.tar.gz的压缩TAR格式问件。在Linux、Mac OS X或任何其他类UNIX系统上,可以通过以下命令解压缩发行包:
tar -xvzf zookeeper-3.4.5.tar.gz
1.1.4第一个ZooKeeper会话
首先我们以独立模式运行ZooKeeper并创建一个会话。要做到这一点,使用ZooKeeper发行包中bin/录下的zkServer和zkCli工具。有经验的管理员常常使用这两个工具来进行调试和管理,同时也非常适合初学者熟悉和了解ZooKeeper
假设你已经下载并解压了ZooKeeper发行包,进入shell,变更目录cd)到项目根目录下,重命名配置文件:
mv conf/zoo_sample.cfg conf/zoo.cfg
最好把data目录移出/tmp目录,防止zookeeper填满了根分区。可以在zoo.cfg文件中修改这个目录的位置
dataDir=/user/me/zookeeper
启动服务器
bin/zkServer.sh start
这个服务器命令使得ZooKeeper服务器在后台中运行。如果在前台中运行以便查看服务器的输出,可以通过以下命令运行
bin/zkServer.sh start-foreground
这个选项提供了大量详细信息的输出,以便允许查看服务器发生了什么
启动客户端
在另一个shell中进入项目根目录,运行一下命令:
bin/zkCli.sh
为了更加了解ZooKeeper,让我们列出根(root)下的所有znode,然后创建一个znode。首先我们要确认此刻znode树为空,除了节点/zookeeper之
外,该节点内标记了ZooKeeper服务所需的元数据树。
ls /
创建节点
create /workers ""
当创建/workers节点后,我们指定了一个空字符串(""),说明我们此刻不希望在这个znode中保存数据。然而,该接口中的这个参数可以使我们保存任何字符串到ZooKeeper的节点中。比如,可以替换""为"workers"。
[zk: localhost:2181(CONNECTED) 3] delete /workers
[zk: localhost:2181(CONNECTED) 4] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 5] quit
Quitting...
2012-12-06 12:28:18,200 [myid:] - INFO [main-EventThread:ClientCnxn$
EventThread@509] - EventThread shut down
2012-12-06 12:28:18,200 [myid:] - INFO [main:ZooKeeper@684] - Session:
0x13b6fe376cd0000 closed
观察到znode/workers已经被删除,并且会话现在也关闭。为了完成最
后的清理,退出ZooKeeper服务器
# bin/zkServer.sh stop
JMX enabled by default
Using config: ../conf/zoo.cfg
Stopping zookeeper ... STOPPED
1.1.5会话的状态和声明周期
会话的生命周期(lifetime)是指会话从创建到结束的时期,无论会话正常关闭还是因超时导导致过期。为了讨论在会话中发生了什么,我们需要考虑会话可能的状态,以及可能导致会话状态改变的事件
一个会话的主要可能状态⼤多是简单明了的:CONNECTING、CONNECTED、CLOSED和NOT_CONNECTED。状态的转换依赖于发⽣在客户端与服务之间的各种事件(见图2-6)
一个会话从NOT_CONNECTED状态开始,当ZooKeeper客户端初始化后转换到CONNECTING状态(图2-6中的箭头1)。正常情况下,成功与ZooKeeper服务器建立连接后,会话转换到CONNECTED状态(箭头2)。当客户端与ZooKeeper服务器断开连接或者无法收到服务器的响应时,它就会转换回CONNECTING状态(箭头3)并尝试发现其他ZooKeeper服务器。如果可以发现另一个服务器或重连到原来的服务器,当服务器确认会话有效后,状态又会转换回CONNECTED状态。否则,它将会声明会话过期然后转换到CLOSED状态(箭头4)。应用也可以显式地关闭会话(箭头4和箭头5)。
注意:发生网络分区时等待CONNECTING
如果一个客户端与服务器因超时断开连接,客户端仍然保持
CONNECTING状态。如果因网络分区问题导致客户端与ZooKeeper集合被
隔离而发生连接断开,那么其状态将会一直保持,直到显式地关闭这个会
话,或者分区问题修复后,客户端能够获悉ZooKeeper服务器发送的会话
已经过期。发生这种行为是因为ZooKeeper集合对声明会话超时负责,而
不是客户端负责。直到客户端获悉ZooKeeper会话过期,否则客户端不能
声明自己的会话过期。然而,客户端可以选择关闭会话。
创建一个会话时,你需要设置会话超时这个重要的参数,这个参数设置了ZooKeeper服务允许会话被声明为超时之前存在的时间。如果经过时间t之后服务接收不到这个会话的任何消息,服务就会声明会话过期。而在客户端侧,如果经过t/3的时间未收到任何消息,客户端将向服务器发送心跳消息。在经过2t/3时间后,ZooKeeper客户端开始寻找其他的服务器,而此时它还有t/3时间去寻找。
当尝试连接到一个不同的服务器时,非常重要的是,这个服务器的ZooKeeper状态要与最后连接的服务器的ZooKeeper状态保持最新。客户端不能连接到这样的服务器:它未发现更新而客户端却已经发现的更新。ZooKeeper通过在服务中排序更新操作来决定状态是否最新。ZooKeeper确保每一个变化相对于所有其他已执行的更新是完全有序的。因此,如果一个客户端在位置i观察到一个更新,它就不能连接到只观察到i\'<i的服务器上。在ZooKeeper实现中,系统根据每一个更新建立的顺序来分配给事务标识符。 图2-7描述了在重连情况下事务标识符(zkid)的使用。当客户端因超时与s 1 断开连接后,客户端开始尝试连接s 2 ,但s 2 延迟于客户端所知的变化。然而,s 3 对这个变化的情况与客户端保持一致,所以s 3 可以安全连接。
以上是关于ZooKeeper架构的主要内容,如果未能解决你的问题,请参考以下文章
SpringCloud系列四:Eureka 服务发现框架(定义 Eureka 服务端Eureka 服务信息Eureka 发现管理Eureka 安全配置Eureka-HA(高可用) 机制Eur(代码片段