189 8069 5689

怎么解析zookeeper原理

今天就跟大家聊聊有关怎么解析zookeeper 原理,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名与空间、网站空间、营销软件、网站建设、蓬安网站维护、网站推广。

一、zookeeper的角色

  • 1. 领导者(leader): 负责进行投票的发起和决议,更新系统状态。

  • 2. 学习者(learner): 包括跟随者是(follower)和观察者(observer)。

  • 3. 跟随者(follower): 用于接受客户端的请求并向客户端返回结果,在选主的过程中参与投票。

  • 4. 观察者(observer): 可以接受客户端连接,将写入请求转发给leader,但observer不参加投票过程,只同步leader的状态,observer的目的是为了扩展系统,提高读取速度。

  • 5. 客户端(client): 请求发起方。

怎么解析zookeeper 原理

二、选举机制

  • Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是回复模式(选主)和广播模式(同步)。当服务启动或者领导者崩溃后,Zab就进入恢复模式,当领导者被选举出来,且大多数Server完成了和leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

  • 为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于哪个leader的统治时期。低32位用于递增计数。

  • 每个Server工作过程中有三个状态:

    • LOOKING : 当前Server不知道leader是谁,正在搜寻。

    • LEADING : 当前Server即为选出来的leader。

    • FOLLOWING : leader已经选举出来,当前Server与之同步。

怎么解析zookeeper 原理

        假设有五台服务器组成的Zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的。假设这些服务器依序启动,来看看会发生什么,如图所示。

  • 1. 服务器1启动,此时只有它一台服务器启动了,它发出去的报文没有任何响应,所以它的选举状态一直是LOOKING状态。

  • 2. 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1、2还是继续保持LOOKING状态。

  • 3. 服务器3启动,根据前面的理论分析,服务器3成为服务器1、2、3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的Leader。

  • 4. 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1、2、3、4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了。

  • 5. 服务器5启动,同4一样当小弟。

三、节点结构

[zk: 127.0.0.1:2181(CONNECTED) 2] get /20181112
hello    #数据
cZxid = 0x4    #创建节点的事务zxid
ctime = Mon Nov 12 15:31:17 CST 2018  #创建时间
mZxid = 0x4    #最后一次更新的事务zxid
mtime = Mon Nov 12 15:31:17 CST 2018  #最后一次更新时间
pZxid = 0x4  #最后一次更新子节点zxid
cversion = 0  #子节点变化号,znode子节点修改次数
dataVersion = 0 #数据变化版本号
aclVersion = 0  #访问控制列表的变化号
ephemeralOwner = 0x0  #如果是临时节点,这个是znode拥有者的session id。如果不是临时节点则是0。
dataLength = 5  #数据长度
numChildren = 0  #子节点数量

四、节点类型

  • Znode有两种类型,短暂的(ephemeral)和 持久的(persistent)。

  • Znode的类型在创建时确定并且之后不能修改。

  • 短暂Znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不可以有子节点。

  • 持久Znode不依赖于客户端会话,只有当客户端明确要删除该持有化Znode时才会删除。

  • Znode有四种形式的目录节点

    • PERSISITENT

    • EPHEMERAL

    • PERSISITENT_SEQUENTIAL

    • EPHEMERAL_SEQUENTIAL

五、写数据流程

怎么解析zookeeper 原理

  • 1. Client 向 ZooKeeper 的 Server1 上写数据,发送一个写请求。

  • 2. 如果Server1不是Leader,那么Server1 会把接受到的请求进一步转发给Leader,因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server,比如Server1和Server2,各个Server写成功后就会通知Leader。

  • 3. 当Leader收到大多数 Server 数据写成功了,那么就说明数据写成功了。如果这里三个节点的话,只要有两个节点数据写成功了,那么就认为数据写成功了。写成功之后,Leader会告诉Server1数据写成功了。

  • 4. Server1会进一步通知 Client 数据写成功了,这时就认为整个写操作成功。

六、观察(watcher)

  • Watcher 在 Zookeeper 是一个核心功能,Watcher可以监控目录节点的数据变化以及子目录的变化,一单这些状态发生变化,服务器就会通知所有设置在这个目录节点上的Watcher,从而每个客户端都很快知道它所关注的状态发生变化,而做出相应的反应。

  • 可以设置观察的操作:exists、getChildren、getData

  • 可以出发观察的操作:create、delete、setData

怎么解析zookeeper 原理

监听原理详解:

  • 1. 首先要有一个main()线程

  • 2. 在main线程中创建Zookeeper客户端,这时就会创建两个线程,一个负责网络连接通信(connet),一个负责监听(listener)。

  • 3. 通过connect线程将注册的监听事件发送给Zookeeper。

  • 4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。

  • 5. Zookeeper监听到有数据或路径变化,就会将这个消息发送给listener线程。

  • 6. listener线程内部调用了process()方法。

看完上述内容,你们对怎么解析zookeeper 原理有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


当前题目:怎么解析zookeeper原理
网页URL:http://cdxtjz.cn/article/ijdoih.html

其他资讯