zookeeper配置参数

先看一张图

zookeeper配置参数_第1张图片

zookeeper配置参数_第2张图片

1、创建了持久节点test,数据为helloworld

2、在持久节点test下创建临时节点tmp,数据为helloworld(在临时节点下不能创建持久节点)

3、使用get命令查看查看test节点下的数据信息,使用ls2查看test下的节点信息

下面主要对出现的这些参数做一个说明:

czxid znode创建时的zxid
mzxid znode的数据最后更新的zxid
ctime 此节点创建时来自epoch的time毫秒数
mtime znode最后更新的毫秒数,来自epoch
version znode数据更新的版本号
cversion znode子节点变更的版本号
aclversion znode的ACL变更的版本号
ephemeralOwner 临时节点的session id,如果不是临时节点,为0
dataLength znode中挂在的数据的长度
numChildren znode中子节点的个数

zoo.cfg参数详解

zoo.cfg在centos7.2下zookeeper伪分布式集群搭建 这篇文章中简单了说明了一些参数,下面将详细说明一下

名称 说明
tickTime

zk中的时间单元,zk中所有时间都是以这个时间为基础,进行整数倍配置的,

如session的最小超时时间是2*tickTime,  每隔tickTime发送一个心跳

clientPort 客户端连接zookeeper服务器的端口号,默认2181
dataLogDir 事务日志输出目录,尽量给事务日志的输出配置单独的磁盘或挂载点,这将极大的提升zk性能
dataDir

存储快照文件目录,默认事务日志也存储在此路径下,建议同时配置dataLogDir,会影响zk

性能,zk会通过org.apache.zookeeper.server.ZKDatabase开加载

globalOutstandingLimit

系统属性:zookeeper.globalOutstandingLimit 默认1000,如果有大量的client,会造成zk server对请求的处理速度小于

client的提交请求的速度,会造成server端大量请求queue滞留而导致OOM,此参数可以控制server最大持有为处理的请

求个数

preAllocSize

系统属性:zookeeper.preAllocSize ,为了避免大量磁盘检索,zk对txn log文件进行空间的预分配,默认为64M,当剩

余空间小于4k时,会再次“预分配”。你可以尝试减小此值,比如当快照较为频繁时,可以适当减小

traceFile

系统属性:requestTraceFile 请求跟踪文件,如果设置了此参数,所有请求将会被记录在traceFile.year.month.day,

类似与nginx的request log,不过此参数会带来性能问题

maxClientCnxns  默认:60, 一个client与server最大的socket连接数,根据IP区分,设置为0,取消此限制。可以避免DOS攻击
clientPortAddress

ip或者hostName,指定监听clientPort的address,此参数可选,默认是clientPort会绑定到所有ip上,在物理server具

有多个网络接口时,可以设置特定的IP

minSessionTimeout 默认 2*tickTime,也是server允许的最小值,如果设置的值过小,将会采用默认值
maxSessionTimeout 默认20*tickTime,允许的最大值
autopurge.snapRetainCount

zk server启动时会开启一个org.apache.zookeeper.server.DatadirCleanupManager的线程,用于清理"过期"的

snapshot文件和其相应的txn log file,此参数用于设定需要被retain保留的文件个数(从QuorumPeerMain跟踪代码)

autopurge.purgeInterval

和上述参数配合使用,清理任务的时间间隔,单位为hours, 可以查看org.apache.zookeeper.server.

DatadirCleanupManager的105行

snapCount

系统属性:zookeeper.snapCount 默认为:100000,在新增Log条数达到snapCount/2 +

 Random.nextInt(snapCount/2)时,将会对zkDatabase内存数据库进行snapshot,将内存中的DataTree反序列化

到snapshot文件数据,同时log计数重置为0,以此循环, snapshot过程中,同时也伴随txn log的新文件创建,

snapshot时使用随机数的原因:让每个server snapshot的时机具有随机且可控,避免所有的server同时snapshot

可见:org.apache.zookeeper.server.SyncRequestProcessor.run()方法实现

electionAlg

选举算法,默认为3,可以选择(0,1,2,3),    0表示使用原生的UDP(LeaderElection), 1表示使用费授权的UDP

2表示使用授权的UDP(AuthFastLeaderElection)  3基于TCP的快速选举(FastLeaderElection)

具体可见:org.apache.zookeeper.server.quorum.QuorumPeer 159行createElectionAlgorithm(electionType);

org.apache.zookeeper.server.quorum.LeaderElection (已被废弃)
org.apache.zookeeper.server.quorum.AuthFastLeaderElection(已被废弃)
org.apache.zookeeper.server.quorum.FastLeaderElection

initLimit

Leader与learner建立连接中  socket通讯read所阻塞的时间(initLimit * tickTime) 如果是Leaner数量较多或者

leader的数量很大, 可以增加此值 ,代码参考:org.apache.zookeeper.server.quorum.LearnerHandler第297行

run()方法

SyncLimit

learner与leader建立连接中,socket通讯read阻塞的时间.其中包括数据同步/数据提交等, 参考代码:

org.apache.zookeeper.server.quorum.Learner
222行connectToLeader()
316行syncWithLeader()

peerType zkserver 类型 observer 观察者, participant参与者 ,默认为参与者
leaderServes

系统属性 zookeeper.leaderServes    leader是否接受client请求,默认为yes即leader可以接受client的连接,在

zk cluster 环境中,当节点数为>3时,建议关闭

cnxTimeout 系统属性:zookeeper.cnxTimeout   leader选举时socket连接打开的时长,只有在electionAlg=3有效
skipACL 系统属性:zookeeper.skipACL   默认为no,是否跳过ACL检查
forceSync

系统属性:zookeeper.forceSync 默认yes 在update执行之前,是否强制对操作立即持久写入txn log文件.关闭

此选项,会造成服务器失效后,尚未持久化的数据丢失

   
   

ACL(Access Control List)

源码:org.apache.zookeeper.ZooDefs.Ids

内置的ACL schemes:

world: 默认方式,意思就是全世界都可以访问

auth: 已经认证通过的用户  在zkCli中通过 addauth digest user:pwd来添加当前上下文中的授权用户

digest: 即 用户名:密码 方式认证

ip: 使用IP地址认证

ACL支持权限

源码:org.apache.zookeeper.ZooDefs.Perms

CREATE :创建子节点

READ: 获取节点数据和列出其子节点

WRITE: 可以设置节点数据

DELETE: 删除子节点

ADMIN: 可以设置权限

Watcher监听:

源码:

org.apache.zookeeper.Watcher.Event.KeeperState
org.apache.zookeeper.Watcher.Event.EventType

KeeperState EventType  触发条件  说明  操作
SyncConnected None 客户端与服务端
成功建立连接
此时客户端和服务器处于连接状态   
NodeCreated Watcher 监听的
对应数据节点被
创建
Create
NodeDeleted Watcher 监听的
对应数据节点被
删除
Delete/znode
NodeDataChanged Watcher 监听的
对应数据节点的
数据内容发生变
setDate/znode
NodeChildChanged Wather 监听的
对应数据节点的
子节点列表发生
变更
Create/child
Disconnected None 客户端与
ZooKeeper 服务
器断开连接
此时客户端和服
务器处于断开连
接状态
 
Expired None 会话超时  此时客户端会话失效,通常同时也会受到
SessionExpiredException 异常
 
AuthFailed--4 None 通常有两种情
况, 1:使用错
误的 schema 进
行权限检查 2:
SASL 权限检查
失败
通常同时也会收到AuthFailedException 异常  

最后附一点有关ZAB协议的相关知识

ZAB 协议: Zookeeper 的核心是原子广播,这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。 Zab 协议有两种模式,它们分别是恢复模式和广播模式。 当服务启动或者在领导者崩溃后, Zab 就进入了恢复模式,当领导者被选举出来,且大多数 server 的完成了和 leader 的状态同步以后,恢复模式就结束了。状态同步保证了 leader server 具有相同的系统状态。一旦 leader 已经和多数的 follower 进行了状态同步后,他就可以开始广播消息了,即进入广播状态。这时候当一个 server 加入 zookeeper 服务中,它会在恢复模式下启动,发现 leader,并和leader 进行状态同步。待到同步结束,它也参与消息广播。

Zookeeper 服务一直维持在 Broadcast 状态,直到 leader 崩溃了或者 leader 失去了大部分的followers 支持。

广播模式需要保证 proposal 被按顺序处理,因此 zk 采用了递增的事务 id (zxid)来保证。所有的提议所有的提议(proposal)都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 为的数字,它32 位是 epoch 用来标识 leader 关系是否改变,每次一个 leader 被选出来,它都会有一个新的 epoch。低 32 位是个递增计数。leader 崩溃或者 leader 失去大多数的 follower,这时候 zk 进入恢复模式,恢复模式需要重新选举出一个新的 leader,让所有的 server 都恢复到一个正确的状态

Zookeeper特性:

Zookeeper 是一个由多个 server 组成的集群,一个 leader,多个 follower,每个 server 保存一份数据副本,全局数据一致
分布式读 follower,写由 leader 实施
更新请求转发,由 leader 实施
更新请求顺序进行,来自同一个 client 的更新请求按其发送顺序依次执行
数据更新原子性,一次数据更新要么成功,要么失败
全局唯一数据视图, client 无论连接到哪个 server,数据视图都是一致的实时性,在一定事件范围内, client 能读到最新数据


你可能感兴趣的:(zookeeper)