Zookeeper详细使用解析!分布式架构中的协调服务框架最佳选型实践

Zookeeper是分布式协调服务,用于管理大型主机,在分布式环境中协调和管理服务是很复杂的过程,Zookeeper通过简单的架构和API解决了这个问题

Zookeeper实现分布式锁 分布式锁三要素: 加锁 解锁 锁超时

Zookeeper数据结构类似树结构,由节点Znode组成

Znode分为四种类型:

持久节点(PERSISTENT): 默认节点类型,创建节点的客户端与Zookeeper断开连接后,节点依旧存在

持久节点顺序节点(PERSISTENT_SEQUENTIAL): 持久节点顺序节点就是在创建持久节点时,Zookeeper根据创建节点的时间顺序给节点进行编号

临时节点(EPHEMERAL): 创建节点的客户端与Zookeeper断开连接后,临时节点会被删除

临时节点顺序节点(EPHEMERAL_SEQUENTIAL): 临时节点顺序节点就是在创建临时节点时,Zookeeper根据创建节点的时间顺序给节点进行编号

应用Zookeeper的临时顺序节点,实现分布式锁

Zookeeper与Redis分布式锁比较:

分布式锁 Zookeeper Redis
优点   1.有封装好的框架,容易实现
2.有等待锁队列,提升抢锁的效率
  Set和Del指令性能高  
缺点   添加和删除节点性能低   1.实现复杂,需要考虑原子性,误删,锁超时问题
2.没有等待锁的队列,只能客户端自旋来等锁,效率低
 
Zookeeper的数据模型

类似数据结构中的树,文件系统中的目录

Zookeeper的数据存储基于节点Znode

Znode的引用方式是路径引用,每一个Znode节点拥有唯一的路径

Znode中的元素

data: Znode存储的数据信息

ACL: 记录Znode的访问权限,即哪些进程和IP可以访问本节点

stat: Znode的各种元数据(数据的数据)

child: 当前节点的子节点引用
Zookeeper的应用场景是读多写少的应用场景:Znode不用来存储大规模的业务数据,用于存储少量的状态和配置信息(Znode存储数据不能超过1MB)

Zookeeper基本操作

创建节点:create

删除节点:delete

判断节点是否存在:exists

获得一个节点的数据:getData

设置一个节点的数据:setData

获取节点下的所有子节点:getChildren
exists,getData,getChildren属于读操作,Zookeeper客户端在请求读操作时,可以选择是否设置watch

Zookeeper事件通知

Watch可以理解成注册在特定Znode上的触发器

当Znode发生改变的时候,调用create,delete,setData方法,将会触发Znode上注册的对应事件,请求的Watch的客户端会接收到异步通知

Zookeeper事件通知的交互过程:

客户端调用getData方法,watch的参数是true,服务端接收到请求,返回节点数据,在对应的Hash表中插入被Watch的Znode路径以及Watcher列表

当被Watch的Znode删除,服务端会查找Hash表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除Hash表中对应的key-value

Zookeeper的一致性

Zookeeper Service集群是一主多从结构

在更新数据时,首先更新到主服务器,再同步到从服务器

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

采用ZAB协议,为了保证主从节点数据的一致性

ZAB协议

ZAB(Zookeeper Automic Broadcast): 解决Zookeeper集群崩溃恢复,主从数据同步问题

ZAB三种节点状态:

Looking:选举状态

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

Leading:Leading(主节点)所处的状态

最大ZXID: 节点本地的最新事务编号,包含epoch计数两部分

ZAB集群崩溃恢复

当Zookeeper的主节点服务器宕机后,集群就会进行崩溃恢复,分成三个阶段:

Leader election(选举阶段):

集群中的节点处于Looking状态,各自向其它节点发起投票,投票当中包含自己服务器的ID和最新事务ID(ZXID)

节点用自身的ZXID和其它节点收到的ZXID作比较,如果发现其它节点的ZXID比自身大,即数据比自己新,就重新发起投票,投票给目前已知最大ZXID所属节点

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

Discovery(发现阶段):

在从节点发现最新的ZXID和事务日志,目的是为了防止在意外情况,选举产生多个Leader

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

各个Follower接收到最新的epoch,返回ACK(响应码)给Leader,带上各自最大的ZXID和历史事务日志,Leader选出最大的ZXID,并更新自身历史日志

Synchronization(同步阶段):

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyjzgy.html