Zookeeper基础

Zookeeper系列

第一章 Zookeeper基础



前言

随着用户规模的增加,数字化内容的增加,分布式应用基本上已经是项目的标配。分布式应用中,由于通信异常、网络分区、节点故障等因素,要实现数据的一致性很难,目前业界解决一致性问题采用的是Paxos算法,但是这个算法实现相对困难。但是开源的Zookeeper,就是针对大型分布式系统的高可用、高性能且具有一致性的开源协调服务,目前在业界被广泛采用,如:Kafka、HBase、Solr、Flink等。

一、技术本质

ZooKeeper is a distributed, open-source coordination service for distributed applications. It exposes a simple set of primitives that distributed applications can build upon to implement higher level services for synchronization, configuration maintenance, and groups and naming. It is designed to be easy to program to, and uses a data model styled after the familiar directory tree structure of file systems. It runs in Java and has bindings for both Java and C.

如上述Zookeeper官网所示,ZooKeeper 主要的系统功能是在分布式系统中协作多个任务。

二、部署架构

ZooKeeper 服务器端运行于两种模式下:独立模式和仲裁模式。独立服务器只有一个单独的服务器,ZooKeeper 状态无法复制。而在仲裁模式下,具有一组 ZooKeeper 服务器,称为 ZooKeeper 集合,它们之间可以进行状态的复制,并同时服务客户端的请求。不过服务器集合并不会让客户端等待每个服务器完成数据保存后再继续,而是在满足仲裁数目的服务器保存或者同步了状态就会返回给客户端。实际生产环境,一般都采用集群部署的方式。
在这里插入图片描述
在这里插入图片描述

三、应用场景

1、数据配置中心

将一些通用的配置信息(数据量小,数据内容再运行时会发生变化)的数据配置在Zookeeper中。应用启动的时候,主动从Zookeeper服务端进行配置信息的获取,同时在指定节点上注册Watcher监听。这样,一旦配置信息发生变化,服务端都会实时通知到所有订阅的客户端,从而达到实时获取最新配置信息的目的。

2、负载均衡中心

使用Zookeeper进行域名配置,内容地址信息,这样就可以通过动态DNS的方案实现负载均衡。

3、分布式协调

通过Zookeeper的Watcher机制 和异步通知机制,可以实现分布式环境下不同应用之间的协调和通知。

4、集群管理

通过Zookeeper的Watcher注册异步通知,以及临时节点特点,可以对集群的方便管理

5、Master选举

通过Zookeeper的节点唯一性、临时节点、Watcher异步通知机制,可以实现Master选举。

6、分布式锁

同master选举

7、分布式队列

临时顺序节点

8、不适合场景

整个 ZooKeeper 的服务器集群管理着应用协作的关键数据,ZooKeeper 不适合用作海量的数据存储,对于需要海量的应用数据的情况,可以使用数据库和分布式文件系统,所以在设计应用时,最佳实践是把应用数据和协同数据独立分开。

三、数据模型

ZooKeeper 采用类似于文件系统的层级树状结构进行管理 Znode,并且暴露操作 API 接口。Znode 的节点类型:在新建 znode 节点,需要指定该节点的类型,不同的类型决定了 znode 节点的行为方式,znode 的类型分为持久节点、时节点、有序节点,组合 4 中类型,持久的,临时的,持久有序的,临时有序的。对于持久节点,只能主动调用 delete 来删除,而临时的 znode,在当创建该节点的客户端崩溃或者关闭了与 ZooKeeper 的连接时,这个节点就会被删除。一般持久类型的 znode 为应用保存数据,即使 znode 的创建者不再属于应用系统时,数据会保存下来而不丢失。临时 Znode 仅当创建者的会话有效时这些信息必须有效保存,会话超时或者主动关闭时,临时 znode 会自动消失。有序 Znode 节点是被分配唯一一个单调递增的整数。
在这里插入图片描述

四、性能量级

在这里插入图片描述
上图是在Zookeeper 3.2 版本,运行在双 2Ghz Xeon 和两个 SATA 15K RPM 驱动器的服务器上,读写请求大小为1KB。从上图可以看出,三个Zookeeper实例,100%读请求,QPS可以达到8万左右

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值