码迷,mamicode.com
首页 > 其他好文 > 详细

ZooKeeper

时间:2018-05-31 14:47:13      阅读:176      评论:0      收藏:0      [点我收藏+]

标签:pad   类型   children   add   名称   poc   查找   存在   exist   

Zookeeper 作为一个分布式的服务框架,主要用来解决分布式集群中应用系统的一致性问题,它能提供基于类似于文件系统的目录节点树方式的数据存储, Zookeeper 作用主要是用来维护和监控存储的数据的状态变化,通过监控这些数据状态的变化,从而达到基于数据的集群管理

1.Znode

像数据结构当中的树,也很像文件系统的目录。基于节点,这种节点叫做Znode。Znode的引用方式是路径引用,类似于文件路径

Znode内容:

  • data:Znode存储的数据信息。
  • ACL:记录Znode的访问权限,即哪些人或哪些IP可以访问本节点。
  • stat:包含Znode的各种元数据,比如事务ID、版本号、时间戳、大小等等。
  • child:当前节点的子节点引用,类似于二叉树的左孩子右孩子。

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

Znode类型:

 

  • PERSISTENT-持久化目录节点:客户端与zookeeper断开连接后,该节点依旧存在
  • PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点:客户端与zookeeper断开连接后,该节点依旧存在,只是Zookeeper给该节点名称进行顺序编号
  • EPHEMERAL-临时目录节点:客户端与zookeeper断开连接后,该节点被删除
  • EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点:客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号

Zookeeper基本操作:

  • create创建节点
  • delete删除节点
  • exists判断节点是否存在
  • getData获得一个节点的数据
  • setData设置一个节点的数据
  • getChildren获取节点下的所有子节点

Zookeeper客户端在请求读操作的时候,可以选择是否设置Watch

当这个Znode发生改变(create,delete,setData),将会触发Znode上注册的对应事件,请求Watch的客户端会接收到异步通知

具体交互过程如下:

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

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

2.Zookeeper

技术分享图片

Zookeeper Service集群是一主多从结构。

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

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

Zookeeper角色介绍:

  • 1、client:分布式中的一个节点,访问服务器的配置信息,周期性向server发送心跳包,server向client回应确认,如果client没有收到回应,则重定向到另一个server
  • 2、server:zookeeper中的一个节点,为client提供所需的服务,给client回应信息表明自己是存活的
  • 3、leader:连接任何一个节点,如果节点出现故障,leader自动修复,在service启动时完成leader的选举
  • 4、follower:听从leader的指令,完成选举工作

问题1:如何保证主从节点的数据一致性?

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

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

ZAB协议所定义的三种节点状态:

  • Looking :选举状态。
  • Following :Follower节点(从节点)所处的状态。
  • Leading :Leader节点(主节点)所处状态。

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

1.Leader election  选举阶段,此时集群中的节点处于Looking状态。

它们会各自向其他节点发起投票,投票当中包含自己的服务器ID和最新事务ID(ZXID)。

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

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

2.Discovery  发现阶段,用于在从节点中发现最新的ZXID和事务日志。

Leader接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch,基于此值加1,生成新的epoch分发给各个Follower。

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

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

问题2:如何保证保证事务的顺序一致性?

zookeeper采用了递增的事务编号(zxid)来标识事务。zxid是一个64位的数字,包含epoch和计数两部分,高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch。低32位用于递增计数。

问题3:ZAB是怎么实现写入数据的?

更新数据的时候,由Leader广播到所有的Follower。其过程如下:

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

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

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

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

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

3.Zookeeper的应用场景

1.分布式锁

利用Zookeeper的临时顺序节点,可以轻松实现分布式锁。

2.服务注册和发现

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

3.共享配置和状态信息

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

 

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

 

ZooKeeper

标签:pad   类型   children   add   名称   poc   查找   存在   exist   

原文地址:https://www.cnblogs.com/mcahkf/p/9115811.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!