Zookeeper工作机制、特点、数据结构、应用场景、配置参数解读

ZK工作机制

从涉及模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,负责存储和管理大家都关心的数据 ,然后接受观察者的注册 ,一旦这些数据的状态发生变化,zk就负责通知已在zk上注册的那些观察者 做出相应的反应。

Zk = 文件系统+通知机制

特点

  1. 一个领导者(Leader),多个跟随者(Follwer)组成的集群
  2. 集群中只要有半数以上节点存活,ZK集群就能正常服务。所以ZK适合安装奇数台服务器。
  3. 全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个Server,数据都是一致的。
  4. 更新请求顺序执行,来自同一个Client的更新请求按其发送顺序依次执行。
  5. 数据更新原子性,一次数据更新要么成功,要么失败。
  6. 实时性,在一定时间范围内,Client能读到最新数据。

数据结构

Zk数据模型的结构与Unix文件系统很类似,整体可以看作是一棵树,每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识。

应用场景

统一命名服务

在分布式环境下,经常需要对应用/服务进行统一命名,便于识别

例如:IP不容易记住,而域名容易记住

统一配置管理

1、分布式环境下,配置文件同步非常常见:

一个要求一个集群中,所有节点的配置信息是一致的,比如Kafaka集群

对配置文件修改后,希望能够快速同步到各个节点上

2、配置管理可交由Zk实现:

可将配置信息写入zk上的一个Znode

各个客户端服务器监听这个Znode

统一集群管理

1、分布式环境中,实时掌握每个节点的状态是必要的。

可根据节点实时状态做出一些调整

2、zk可以实现实时监控节点状态变化

可将节点信息写入zk上的一个ZNode

监听这个ZNode可获取他的实时状态变化

服务器动态上下线

客户端能实时洞察到服务器上下线的变化

软负载均衡

在ZK记录每台服务器的访问数,让访问数量少的服务器去处理最新的客户端请求

ZK配置参数解读

xml 复制代码
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=/tmp/zookeeper
# the port at which the clients will connect
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the 
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1
dataDir=D://soft//apache-zookeeper-3.5.7-bin//data
dataLogDir=D://soft//apache-zookeeper-3.5.7-bin//log

tickTime

通信心跳时间,zk服务器与客户端,客户端与客户端,每隔两秒发送一次心跳,单位毫秒

initLimit

Leader与Follower初始通信时限

Leader与Follower初始连接时能容忍的最多心跳数,10次*2秒,也就是要在20秒内建立连接

syncLimit

Leader与Follower同步通信时限

Leader和Follower直接通信时间如果超过syncLimit*tickTime,Leader认为Follwer死掉,从服务器列表中删除Follwer。

dataDir

保存ZK中的数据。

注意:默认的tmp目录,容易被Linux系统定期删除,所以一般不用默认的tmp目录。

clientPort

客户端连接端口,通常不做修改

下一篇:Zookeeper在Windows环境的安装

https://blog.csdn.net/qq_40525480/article/details/135088151

相关推荐
敲代码的嘎仔1 小时前
从集群锁失效到异步领券:我用分布式锁 + Redisson + MQ 把领券接口 RT 从 200ms 压到 15ms
java·数据库·redis·分布式·缓存·ai·wpf
陈聪.4 小时前
Kubernetes 集群网络插件迁移:从 Flannel 到 Calico 实战总结
云原生·kubernetes
lauo4 小时前
FDE的终极形态:从“一个人”到“一个网络”
人工智能·分布式
Spider Cat 蜘蛛猫7 小时前
微服务- 自动审核商家入驻
微服务·云原生·架构
陈聪.7 小时前
Kubernetes Service 与 Ingress 知识总结
云原生·容器·kubernetes
雾隐隐o9 小时前
Kafka 集群搭建:从核心概念到多节点部署
分布式·kafka
分布式存储与RustFS1 天前
RustFS 多协议接入全景:S3 之外,Swift/Keystone 与 SFTP/FTPS 怎么选
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准
IT大白鼠1 天前
MySQL 分布式集群系列 · 第八篇(收官)——NDB 集群面试高频题 +架构总结与未来演进
分布式·mysql·面试
IT大白鼠1 天前
MySQL 分布式集群系列 · 第七篇——生产调优实战:NDB 性能、内存、高可用全方位优化
数据库·分布式·mysql
分布式存储与RustFS1 天前
在 Kubernetes 上用 RustFS Operator 给 Tenant 开 KMS 加密:spec.encryption 实战
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准