必威体育Betway必威体育官网
当前位置:首页 > IT技术

zk——你知道的zk是这样的吗

时间:2019-06-30 10:43:25来源:IT技术作者:seo实验室小编阅读:73次「手机版」
 

zk

你平常使用zookeeper做什么?是分布式协调服务、共享变量、协调锁资源、还是提供命名空间

好了,接下来我们以提问的形式来打开话题:

你知道zk能用来做什么?

你知道zk的数据模型吗?

你知道zk的数据结构吗?

你会zk操作基本命令吗?

这些命令是如何事件通知?

zk是如何保证一致性的?

你会用zk做什么?

zk数据模型

了解一门技术,先知道它大致长得啥样,这才好的去进一步认识。

zk的数据模型:

很像数据结构中的树,也像文件系统的目录;

zk的数据存储同样基于节点,叫Znode;

但引用方式是:路径引用,类似于文件路径,让每一个节点拥有唯一的路径

这里讲到了Znode (zk的节点):

Znode数据结构

它的主要属性有data、AC++L、child、stat

data:Znode存储的数据信息。

ACL:记录Znode的访问权限,即哪些人或哪些ip可以访问本节点。

stat:包含Znode的各种元数据,比如事务ID、版本号时间戳、大小等等。

child:当前节点的子节点引用,类似于二叉树的左孩子右孩子。

注意:Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据,而是用于存储少量的状态和配置信息,每个节点的数据最大不能超过1MB。

基本操作

Zookeeper包含了哪些基本操作呢?这里列举出比较常用的API:

create:创建节点

delete:删除节点

exists:判断节点是否存在

getData:获得一个节点的数据

setData:设置一个节点的数据

getchildren:获取节点下的所有子节点

exists,getData,getChildren属于读操作。Zookeeper客户端在请求读操作的时候,可以选择是否设置Watch。

讲到这,大家可能会联想到我们平常使用的zkclient 这插件,其实这里面的命令都是通过if-else这样判断单独调用远程server的命令,目前博主对这个jar通信方式还在研究,会单独抽出时间整理一下。

zk客户端的数据是如何与server数据保持一致,其中是离不开Watch动作的?

事件通知

Watch是什么意思呢?

我们可以理解成是注册在特定Znode上的触发器。当这个Znode发生改变,也就是调用了create,delete,setData方法的时候,将会触发Znode上注册的对应事件,请求Watch的客户端会接收到异步通知。

具体交互过程如下:

1.客户端调用getData方法【getData(nodePath,isWatch)】,watch参数是true。服务端接到请求,返回节点数据,并且在对应的哈希表里插入被Watch的Znode路径,以及Watcher列表。

2.当被Watch的Znode已删除,服务端会查找哈希表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除哈希表中对应的Key-Value。

zk的应用

讲到zk的应用,肯定得想到zk有什么作用,才能知道它能做什么?

zk可以用来 协调分布式服务、共享变量、协调锁资源、提供命名空间,其实这些作用是依赖zk的数据模型以及ZNode的数据结构,也可以从侧面反映出,先有功能需求 才能想出 好的数据模型及数据结构。

好了,我们平常会将zk用来做什么?

1.分布式锁

这是雅虎研究员设计Zookeeper的初衷。利用Zookeeper的临时顺序节点,可以轻松实现分布式锁。

2.服务注册和发现

利用Znode和Watcher,可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。

3.共享配置和状态信息

Redis的分布式解决方案Codis,就利用了Zookeeper来存放数据路由表和codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。

此外,Kafka、HBase、Hadoop,也都依靠Zookeeper同步节点信息,实现高可用。

4.其实它还可以用来解决分布式Id生成,只不过zk的zNode支持的数量不够多,因为zk主要使用场景是那种读多写少的,

好了,插个小广告,我自己 基于netty4+twitter-snowFlake 写了个分布式Id生成之服务:HTTPs://github.com/Zeb-D/distributed-id ;关于这开源项目,我后续会单独写个系列的博客

zk的集群

集群单纯地防止单个zk挂了,导致所有依赖zk的服务都不可用(或者被影响到),其实zkClient 这会在调用方 会缓存下来一下zk Server的数据,具体是怎么个样子,可能需要单独研究分析下,博主目前不知道怎么去分析,希望各位老道们给点建议,谢谢!

ZookeeperService集群是一主多从结构。

zk集群图

在更新数据时,首先更新到主节点(这里的节点是指服务器,不是Znode),再同步到从节点。

在读取数据时,直接读取任意从节点。

说到这一主多从集群方式,大家可能会联想到mysql集群方式,这种集群方式保证服务高可用,但又是如何保证各个主从节点任意时间的数据一致性呢?

zk的一致性

为了保证主从节点的数据一致性,Zookeeper采用了ZAB协议,这种协议非常类似于一致性算法Paxos和Raft。

ZAB协议

我们需要首先了解ZAB协议所定义的三种节点状态:

Looking :选举状态。

Following:Follower节点(从节点)所处的状态。

Leading:Leader节点(主节点)所处状态。

我们还需要知道最大ZXID的概念

最大ZXID也就是节点本地的最新事务编号,包含epoch和计数两部分。epoch是纪元的意思,相当于Raft算法选主时候的term。

zk主节点故障恢复

假如Zookeeper当前的主节点挂掉了,集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段:

1.Leader election

选举阶段,此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。

接下来,节点会用自身的ZXID和从其他节点接收到的ZXID做比较,如果发现别人家的ZXID比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的ZXID所属节点。

每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。

2.Discovery

发现阶段,用于在从节点中发现最新的ZXID和事务日志。或许有人会问:既然Leader被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?

这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个Leader的情况。

所以这一阶段,Leader集思广益,接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。

各个Follower收到全新的epoch后,返回ACK给Leader,带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID,并更新自身历史日志。

3.Synchronization

同步阶段,把Leader刚才收集得到的最新历史事务日志,同步给集群中所有的Follower。只有当半数Follower同步成功,这个准Leader才能成为正式的Leader。

自此,故障恢复正式完成。

ZAB写数据

在上面的zk集群图,可用看出zk客户端是轮询到某个zk Server的,那这是如何工作及保证数据一致性的,这主要用的了广播 Broadcast,简单来说,就是Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower。其过程如下:

1.客户端发出写入数据请求给任意Follower。

2.Follower把写入数据请求转发给Leader。

3.Leader采用二阶段提交方式,先发送Propose广播给Follower。

4.Follower接到Propose消息,写入日志成功后,返回ACK消息给Leader。

5.Leader接到半数以上ACK消息,返回成功给客户端,并且广播Commit请求给Follower。

Zab协议既不是强一致性,也不是弱一致性,而是处于两者之间的单调一致性。它依靠事务ID和版本号,保证了数据的更新和读取是有序的。

文章已同步到个人学习仓库中:https://github.com/Zeb-D/my-review,欢迎品读及star。

相关阅读

ZKTECO 资料

数据库表LeaveClass:各种休假设定LeaveClass1:迟到早退旷工设定MaChines : 软件连接设备设定SchClass : 设定打开时间Systemlog :

分享到:

栏目导航

推荐阅读

热门阅读