文中摘自微信公众平台「HelloGitHub」，作者HelloGitHub 。转截文中请联络HelloGitHub微信公众号。
文中是 HelloZooKeeper 系列产品的最终一篇文章，下面关键聊一聊面试中假如被问起 ZooKeeper的问题怎样回应，还可以作为学完结系列产品的检测。
你准备好了吗?面试逐渐喽~
一、仿真模拟面试
总算赶到重中之重了，本小标题我能从在网上寻找一些有关 ZK 的面试题开展分析解读，而且立在面试官的基本上剖析知识点，坚信看了这一节，出来面试再遇到 ZK 有关的问题你便能一往无前、无坚不摧!
我先给大伙儿仿真模拟一个面试的情景：
面试官：我看你个人简历上使用过 ZK，能帮我详细介绍下吗?你是怎么理解 ZK 的功能呢?
(假如你将百科中的界定背为他听，我也只能说 666，千万不要那样，会被他人当作二愣子。)
我：我的了解 ZK 是一个摆脱于运用的第三方过程，相近的数据库查询，线程池，Redis 等全是饰演这一人物角色，有着一定的数据储存和查看能力，可以使我们在如今全是分布式部署的运用中间“传送”数据信息，次之 ZK 适用的调整通告，让运用可以在一些业务场景中认知到信息的转变并立即做出对应的反映。最终，ZK 自身也适用群集布署具备高可用性的特性，是一个稳定的第三方分布式数据库。
面试官：嗯，你刚提及了调整通告，能细心跟我聊一聊 ZK 是如何去完成的吗?
我：各种各样计算机语言的服务端都是会对这一调整通告开展抽象化，通常必须开发人员申明一个 callback 的目标，在 Java 的手机客户端中这一插口是 Watcher，ZK 服务器端给予了一些方式，例如 getData、exists 或是最新版中的 addWatch 都能够用于向 ZK 申请注册调整通告，而向服务器端推送的调整通告，只能告知服务器端我现阶段的这一方向必须被通告，服务器端获知后，会在存储空间中记下来，途径和手机客户端相互关系，手机客户端自身也必须记下来，途径和实际调整的关联。当被定阅的途径产生事情的情况下，各种各样删改改吧，服务器端便会从运行内存中的纪录去查询是否有必须通告的手机客户端，有得话会上传一个通告的要求给手机客户端，客户端接到通告后，便会从当地的纪录中取下相匹配的调整目标去实行 callback 方式!
(具体情况，我认为面试官很有可能不容易使你一直说下来，应该是相互之间聊的一个情况)
面试官：嗯，说得挺详尽，那么你刚提及的 getData、exists、 addWatch 三种申请注册有什么不同吗?
我：getData、exists 及其 getChildren 申请注册的通告全是一次性的，当服务器端通告过一次后，便会删掉运行内存中的纪录，以后假如依然必须通告得话，手机客户端就需要去再次申请注册，而 addWatch 注册的调整通告是永久的，只必须申请注册一次可以一直被通告。
面试官：嗯好，你刚才还提起了 ZK 有一定的数据储存能力，你能说说 ZK 是怎么保存和梳理数据信息的吗?
我：ZK 的信息反映在两一部分。
面试官：哦?哪两部分?
我：运行内存中合硬盘上。
面试官：那么你先说说运行内存里 ZK 是怎么储存数据信息
我：从逻辑关系上而言，ZK 运行内存中的数据信息实际上是一个树结构，从 / 根节点逐渐，逐步往下用 / 切分，每一个连接点下边还能够有好几个子连接点，就类似 Unix 中的文件目录构造，但在真实中，ZK 是应用一个 HashMap 去储存全部树结构的数据资料的，key 是相应的全途径字符串数组，value 则是一个连接点目标，包括了连接点的各类信息内容。
面试官：能说说你觉得为什么要那么设计方案吗?
(实际上我认为一般面试官不容易如此问，下列回应也就是我自己的猜测)
我：最先 HashMap 查看速率迅速，是 Java 标准库中一个十分关键的算法设计，在很多地区都是有使用。ZK 自身并不一定排列或是是范畴求值的实际操作，因此 HashMap 彻底可以达到查看的要求。对于为何逻辑性上应设计方案成树结构，父子俩连接点，这一很有可能是由于这一构造和 Unix 系统文件很像，十分有利于了解及其根据途径开展统计数据的归类，并且全新的 ZK 中有一些作用是依靠了父子俩递归法这一特点的(例如 addWatch)，如果是一般的 key-value 是不能满足的。
面试官：嗯好，那么你再讲说硬盘上 ZK 是怎么储存信息的呢?
我：ZK 在硬盘上要求了二种文件属性，一种是 log 文档，一种是 snapshot。log 文档是增加量纪录，承担对每一个写要求开展储存，snapshot 文档是全量纪录，是对内存条的快照更新。
面试官：ZK 是怎么确保运行内存中的信息和硬盘中的数据资料的一致性呢?
我：真真正正的强一致性，ZK 没法确保。针对每一次的写要求，ZK 是采用先纪录硬盘再改动运行内存的，因此确保了假如发生意外得话，优先选择纪录硬盘可以尽量的确保数据的详细。假如 ZK 是一切正常撤出得话，也会强制性刷硬盘文档和转化成 snapshot，确保了一致性，但如果是异常撤出得话，极端化情形下的一部分数据信息是会遗失的。
面试官：你刚也提及了 ZK 自身还可以群集布署的?能想聊一点吗?
我：ZK 的环境变量 zoo.cfg 中可以配备别的结点的信息内容，每个网络节点根据 dataDir 文件目录下的 myid 文档开展区别，不一样连接点中间可以互相通讯，手机客户端连上群集中的任何一个连接点都能够开展通讯。
面试官：ZK 群集中有几种不一样的人物角色?你清楚吗?
我：有 Leader、Follower、Observer 三种人物角色。
面试官：说说她们中间的差别吧
我：群集含有且也只能有一个 Leader，Leader 承担对所有群集的写要求事务管理开展递交，在一个群集挑选出 Leader 以前是没法对外开放给予服務的。Follower 和 Observer 都只有解决读要求，差别是 Follower 有选举权可以参加 Leader 的竟选，Observer 没法参加 Leader 的竟选。
面试官：那么你可以跟我讲下，大选 Leader 借助什么信息内容吗?
我：每一个连接点都是会维护保养三个最重要的信息内容：epoch、zxid、myid。epoch 意味着大选的轮数，优先选择较为，假如同样则再次较为下一级。zxid 意味着本连接点解决过的较大事务管理 ID，越大意味着现阶段连接点经手人的写要求越多，了解的也就越多，第二优先较为，假如还同样则较为 myid，myid 全部群集中不可以反复，因此最后一定能分离出来输赢。获胜的连接点入选 Leader。
(精确的说，epoch 和 zxid 是一个字段名，一个统计在高 32 位，一个记录在低 32 位)
面试官：不一样连接点中间如何通讯呢?如何去开展大选?
我：每一个 ZK 连接点在运行的情况下，会根据载入环境变量中的群集信息内容，与别的连接点创建 Socket 联接，群集间的通讯便是根据这一 Socket。每一个连接点大选的情况下都把自身以为的侯选人信息内容广播节目出来，与此同时也接受来源于别的结点的侯选人信息内容，根据较为后，不成功的一方会变更自身的侯选人信息内容并再次开展广播节目，不断直到某一个连接点获得过半数网络投票，大选就完成了。
面试官：不一样的连接点人物角色，在解决读写能力要求上有什么区别吗?你先聊一聊 Leader 吧
我：不错，Leader 做为群集中的大哥，承担对接收的写要求进行提议 PROPOSAL，告知别的连接点现阶段接到一个写要求，别的连接点接到后，会在当地开展存档，实际上便是载入文档輸出流，结束后会上传一个 ACK 给 Leader，Leader 统计分析到过半数的 ACK 以后会再度发给别的连接点一个 COMMIT，别的连接点接到 COMMIT 以后就可以改动运行内存数据信息了。读要求得话不用提议立即查看运行内存中的信息回到就可以。
面试官：那 Follower 或 Observer 呢?
我：她们接到读要求是一样的，立即回到当地的运行内存数据信息就可以。可是写要求得话，会将现阶段要求发送给 Leader，随后由 Leader 去解决，就和先前的程序流程是一样的。
面试官：不一样的要求 ZK 是怎样确保次序呢?
我：这一次序的确保最后是贯彻落实在一个先进先出法的序列，优先选择进该序列的要求会被先解决，因此能确保次序。
面试官：不一样的手机客户端的要求如何确保次序呢?A 先上传了一个建立连接点，在该访问请求回到以前，B 推送了一个查看该连接点，B 会堵塞到 A 实行结束再查看吗?或是立即回到查看不上连接点?
我：B 会立即回到查不出。不一样的手机客户端相互之间的次序 ZK 不确保，缘故是在最底层 ZK 是根据一个 Map 去各自置放不一样的手机客户端的要求的，不一样的手机客户端的 key 是不一样的，而这一 Map 的 value 则就是我刚提及的先进先出法的序列。因此仅有同一个手机客户端的要求能被次序实行，不一样的手机客户端是不能保障的。
面试官：能说说不一样的手机客户端的 key 是啥吗?如何确保不一样。
我：每一个手机客户端在联接至 ZK 之后被分派一个 sessionId，这一 sessionId 是根据当前时间戳、连接点的 myid 和一个增长特点转化成的一个 long 种类字段名，可以确保不容易反复。
面试官：说到 session，你了解 ZK 的对话是怎么保持的吗?
我：你问的是手机客户端和服务器端中间的对话吗?
面试官：是的，你能告诉我说吗?
我：每一个手机客户端在联接 ZK 的过程中会与此同时汇报自身的中断時间，再加上刚的 sessionId，ZK 的服务器端会在当地维护保养一个镜像关联，根据测算可以计算出该 sessionId 的中断時间，而且 ZK 自身也有一个 tickTime 的配备，根据一个优化算法可以将不一样手机客户端不一样超時间都投射到同样间距的时间点上，再将这一请求超时時间和 sessionId 关联存起來。
面试官：投射到一致的时间点上有哪些好处呢吗?
我：那样服务器端在起动后，后台管理会有一个进程，根据这一统一的间隔时间，取下 session 到期的手机客户端，向她们推送对话到期的信息，巨大的节省了特性。
面试官：手机客户端是如何去升级对话的中断時间呢?
我：最先手机客户端的每一次实际操作都是会更新这一请求超时時间，次之手机客户端务必设计方案一个 PING 的实际操作，用以在手机客户端空余的情况下积极去更新对话请求超时時间，避免到期。
面试官：除开手机客户端和服务器端中间的对话，也有其他吗?
我：服务器端和服务端中间也是有心率，并且服务器端的心率是由 Leader 积极进行的，向其它连接点推送 PING 要求，而其它连接点接到 PING 后，必须把当地的对话信息内容一并发给 Leader。
编不下来了，上边一些题具备我明显的客观喜好性，我认为假如面试官是个菜鸡得话，这种问题绝大多数都问不出来，因此关键不是取决于我怎么回答，反而是如果你对后面的基本原理不在话下时，当然上帝挡杀神，佛挡杀佛。
我讲说我觉得较为主要的好多个特点：
调整通告，ZK 别的基本原理可以不明白，可是如何使用调整是一定要清楚的。
大选，ZK 极具特点的一个特性，基本上都是会问一下。
分布式锁，说清晰二种文档的差别。
对话，会话的定义，及其如何保持。
最终根据一个面试技巧培训回应了一下我觉得 ZK 中较为有特性的面试的问题，假如我们对面试的问题有没有什么疑惑还记得留言板留言帮我噢～务必给大家分配上!
二、在网上考试真题
我绝大多数问题是在网上立即搜的 ZooKeeper面试问题(2020最新版本)可是过虑了一些太 low 的题型。考试真题保存如下所示：
4. ZooKeeper 如何确保主从关系节点的情况同歩?
我上边讲了 Leader 在接收到写请求后，会进行提案，随后等候别的节点的 ACK，这一 ACK 是规定过半数根据才可以坚持下去的，因此能接到过半数的 ACK 表明群集中的一半以上都早已完成了系统盘的存档，当然是确保了主从关系中间的数据库同步。
5. 四种种类的数据信息节点 Znode
我先前的内容中有详细介绍如今 ZK 中有 7 种节点种类，关于新节点的基本原理我还没讲，因此他假如那么问了你能很官方网的回应他：
他一般后边会然后问两者之间的差别，临时性节点会伴随着客户端的对话断掉而自行删掉，基本原理便是在建立临时性节点的情况下，服务器端会维护保养一个 sessionId 和它相应的临时性节点路径目录，当关掉对话时，把这个目录里的路径都拿出来一一删掉就可以。而次序节点的区分就取决于 ZK 会自動为路径再加上数据的后缀名，我不相信爱情。
高并发建立时，次序节点如何确保后缀名数据唯一呢?
ZK 的请求是放进序列里一个个解决的，因此实际上并没所说的高并发，前一个请求解决完再处理下一个请求，当然就能确保后缀名数据的唯一性了。
10. ACL 权限管理体制
ZK 将管理权限分成两类，两大类又能再次细分化：
客户端的人物角色管理权限
- IP
- 用户名密码
- world，最广泛的管理权限，也就是沒有管理权限
- super，独特的用户名密码，等同于管理权限
节点的数据权限
- Create，建立
- Delete，删掉
- Read，读
- Write，写
- ACL，读写能力管理权限
11. Chroot 特点
chroot 是 ZK 设计方案给客户端的取名空间隔离，做为不一样客户端的根节点，由客户端去维护保养，总体来说便是推送请求以前把 chroot 的路径拼凑上，再去请求服务器端。chroot 针对服务器端是通透的，彻底不清楚的。
15. 数据库同步
- Learner 和 Leader 中间同歩数据信息是一个较为难熬和复杂性的全过程，总体来说可以大体分成下列流程：
- Learner 汇报自身的信息内容给 Leader
- Leader 依据 Learner 信息内容决策应用哪种同歩方式
- DIFF，立即从近期的 500 个提案中数据恢复，立即推送提案就可以
- TRUNC，通常产生于 Learner 是前 Leader，必须降权自身的数据信息做到和 Leader 一致
- SNAP，Leader 立即推送全部运行内存快照更新给 Follower
- Leader 和 Learner 逐渐同歩
- 同步进行后逐渐对外开放给予服务项目
三、配置全集
托大伙儿的福，我将 ZK 的源代码所有(肝爆)访问了一遍，找到最少 99% 的配置选择项，ZK 的配置大概可以分成 3 种：
- 启动命令行传到的主要参数
- zoo.cfg 配置文档中的主要参数
- 现阶段系统变量中的主要参数
3.1 命令行参数
命令行参数非常少，并且沒有相匹配的配置名字，这儿我简易讲解下：
单机只适用二种类型的命令传参
- 客户端监视端口号加 data 文件目录，上一节源代码调节选用的便是这一个方式，例如: 2181 /your/zk/data/path
- 或是只传一个主要参数，zoo.cfg 的路径，例如：/your/zoocfg/path
群集版更简易只适用 zoo.cfg 的路径一个主要参数
3.2 zoo.cfg 文档中的配置
我细心查询源代码的过程中发觉有一些配置具体功效时必须测算又或是一鱼两吃，被好几个位置应用，因此难以一步到位的讲明白，因此下边的详细介绍仅作参考，配置项加星号(*)的就是我将来准备篇首解读的。
配置项
初始值（企业）
详细介绍
| dataDir |
/tmp/zookeeper |
储放 snapshot、myid 文档路径 |
| clientPort |
2181 |
监视客户端请求端口号 |
| tickTime |
2000（ms） |
危害手机客户端会话查验间隔、服务端中间心跳间隔 |
| syncLimit |
5 |
tickTime * syncLimit 决策了服务端心跳请求超时时间 |
| initLimit |
10 |
tickTime * initLimit 决策了 ACK 的请求超时时间 |
| dataLogDir |
和 dataDir 一致 |
储放 log 文件路径 |
| minSessionTimeout |
tickTime * 2 |
客户端的请求超时时间最小值 |
| maxSessionTimeout |
tickTime * 20 |
客户端的超时时间最大值 |
| electionAlg |
3 |
大选优化算法（1，2 已被废弃） |
| localSessionsEnabled* |
false |
开启当地会话 |
| localSessionsUpgradingEnabled* |
false |
当地会话可以升级成全局会话 |
| clientPortAddress |
- |
手机客户端的 host 规定，不配备得话可以接纳任意发向 2181 的要求 |
| secureClientPort |
- |
SSL 安全性端口号 |
| secureClientPortAddress |
- |
SSL 安全 host |
| observerMasterPort* |
- |
使 Observer 根据 Follower 去掌握集群中的大选状况 |
| clientPortListenBacklog |
50 |
TCP 服务端用以临时性储放已完成三次握手的请求的队列的较大长短 |
| maxClientCnxns |
60 |
手机客户端最大连接数 |
| connectToLearnerMasterLimit |
0 |
决策了 Follower 联接 Leader 的中断時间 |
| quorumListenOnAllIPs |
false |
服务端是不是接纳来源于随意 IP 详细地址的请求 |
| peerType |
- |
选项 observer / participant，决策节点人物角色 |
| syncEnabled |
true |
Learner 是不是必须当地持久化文件 |
| dynamicConfigFile* |
- |
动态性配备途径 |
| autopurge.snapRetainCount |
3 |
保留多少个全新的 snapshot 文件 |
| autopurge.purgeInterval |
0（小时） |
间隔多长时间开展一次 snapshot 的清除 |
| standaloneEnabled |
true |
是不是容许单机方式运行 |
| reconfigEnabled* |
false |
是不是容许动态配备 |
| sslQuorum |
false |
集群间是不是应用 SSL 通讯 |
| portUnification |
false |
是不是容许不安全联接 |
| sslQuorumReloadCertFiles |
false |
启用密钥升级时自动加载 |
| quorum.auth.enableSasl |
false |
启用集群间 SASL 鉴权 |
| quorum.auth.serverRequireSasl |
false |
|
| quorum.auth.learnerRequireSasl |
false |
|
| quorum.auth.learner.saslLoginContext |
QuorumLearner |
|
| quorum.auth.server.saslLoginContext |
QuorumServer |
|
| quorum.auth.kerberos.servicePrincipal |
zkquorum/localhost |
|
| quorum.cnxn.threads.size |
20 |
集群间多线程建立连接线程池较大线程数 |
| jvm.pause.info-threshold.ms |
1000（ms） |
INFO 输出中止统计阈值 |
| jvm.pause.warn-threshold.ms |
10000（ms） |
WARN 输出中止统计阈值 |
| jvm.pause.sleep.time.ms |
500（ms） |
JVM 中止统计线程 sleep 间距 |
| jvm.pause.monitor* |
false |
是不是启用 JVM 中止统计 |
| metricsProvider.className* |
DefaultMetricsProvider（全路径） |
统计完成类路径 |
| multiAddress.enabled |
false |
|
| multiAddress.reachabilityCheckTimeoutMs |
1000（ms） |
|
| multiAddress.reachabilityCheckEnabled |
true |
|
| （以开头）server.* |
|
集群配置 |
| （以开头）group* |
|
分类配置 |
| （以开头）weight* |
|
权重值 |
| （以开头）metricsProvider.* |
|
自定的统计分析配置 |
以上便是 3.6.2 中 zoo.cfg 全部的官方网配置选择项了
3.3 环境变量配置
Java 程序流程要想指定环境变量有这两种方式：
只要在运行的情况下在后面再加上 -DpropertyKey=propertyValue 就可以
ZK 还适用一种简易的形式是在 zoo.cfg 中立即指定(指定时不用写 zookeeper. 的前缀)。只需并不是在上面 2.2 中 ZK 自身界定的配置项里，ZK 运行的情况下载入这种配置会全自动帮她们加上 zookeeper. 前缀并添加现阶段环境变量中
假如该配置是 follower.nodelay，就只有用第一种方法加上环境变量了。
使我们也一起来看看 ZK 自身界定了什么环境变量配置吧
配置项
初始值
配置
| zookeeper.server.realm* |
- |
手机客户端配置 |
| zookeeper.clientCnxnSocket |
ClientCnxnSocketNIO（全路径） |
客户端配置，通讯的完成类 |
| zookeeper.client.secure |
true |
客户端配置 |
| zookeeper.request.timeout |
0 |
客户端配置，多线程 API 请求超时时间 |
| zookeeper.server.principal |
- |
客户端配置 |
| zookeeper.sasl.client.username |
zookeeper |
客户端配置 |
| zookeeper.sasl.client.canonicalize.hostname |
true |
客户端配置 |
| zookeeper.disableAutoWatchReset |
false |
客户端配置，会话请求超时自动清空 watcher |
| zookeeper.sasl.clientconfig |
- |
|
| zookeeper.sasl.client |
true |
启用 SASL |
| zookeeper.ssl(.quorum).authProvider |
x509 |
SSL 完成类，加 quorum 的是服务端的配置，下同 |
| zookeeper.ssl(.quorum).protocol |
TLSv1.2 |
|
| zookeeper.ssl(.quorum).enabledProtocols |
- |
|
| zookeeper.ssl(.quorum).ciphersuites |
依据不一样的 jvm 版本 |
|
| zookeeper.ssl(.quorum).keyStore.location |
- |
|
| zookeeper.ssl(.quorum).keyStore.password |
- |
|
| zookeeper.ssl(.quorum).keyStore.type |
- |
|
| zookeeper.ssl(.quorum).trustStore.location |
- |
|
| zookeeper.ssl(.quorum).trustStore.password |
- |
|
| zookeeper.ssl(.quorum).trustStore.type |
- |
|
| zookeeper.ssl(.quorum).context.supplier.class |
- |
|
| zookeeper.ssl(.quorum).hostnameVerification |
true |
|
| zookeeper.ssl(.quorum).crl |
false |
|
| zookeeper.ssl(.quorum).ocsp |
false |
|
| zookeeper.ssl(.quorum).clientAuth |
- |
|
| zookeeper.ssl(.quorum).handshakeDetectionTimeoutMillis |
5000（ms） |
|
| zookeeper.kinit |
/usr/bin/kinit |
|
| zookeeper.jmx.log4j.disable |
false |
禁用 jmx log4j |
| zookeeper.admin.enableServer* |
true |
是不是启用 Admin Server |
| zookeeper.admin.serverAddress* |
0.0.0.0 |
|
| zookeeper.admin.serverPort* |
8080 |
|
| zookeeper.admin.idleTimeout* |
30000 |
|
| zookeeper.admin.commandURL* |
/commands |
|
| zookeeper.admin.httpVersion* |
11 |
|
| zookeeper.admin.portUnification |
false |
|
| zookeeper.DigestAuthenticationProvider.superDigest |
- |
管理员账号密码 |
| zookeeper.ensembleAuthName |
- |
|
| zookeeper.requireKerberosConfig |
- |
|
| zookeeper.security.auth_to_local |
DEFAULT |
|
| （以开头）zookeeper.authProvider.* |
- |
自定义 scheme 校验规则 |
| zookeeper.letAnySaslUserDoX |
- |
|
| zookeeper.SASLAuthenticationProvider.superPassword |
- |
|
| zookeeper.kerberos.removeHostFromPrincipal |
- |
|
| zookeeper.kerberos.removeRealmFromPrincipal |
- |
|
| zookeeper.X509AuthenticationProvider.superUser |
- |
|
| zookeeper.4lw.commands.whitelist* |
- |
四字命令白名单 |
| zookeeper.preAllocSize |
65536 * 1024 |
|
| zookeeper.forceSync |
yes |
|
| zookeeper.fsync.warningthresholdms |
1000（ms） |
fsync 告警阈值 |
| zookeeper.txnLogSizeLimitInKb |
-1（KB） |
log 文件大小 |
| zookeeper.datadir.autocreate |
true |
data 目录全自动创建 |
| zookeeper.db.autocreate |
true |
|
| zookeeper.snapshot.trust.empty |
false |
不信任空的 snapshot 文档 |
| zookeeper.snapshot.compression.method |
空字符串 |
snapshot 文件压缩完成 |
| zookeeper.commitProcessor.numWorkerThreads |
CPU 核心数 |
|
| zookeeper.commitProcessor.shutdownTimeout |
5000（ms） |
|
| zookeeper.commitProcessor.maxReadBatchSize |
-1 |
|
| zookeeper.commitProcessor.maxCommitBatchSize |
1 |
|
| zookeeper.fastleader.minNotificationInterval |
200（ms） |
收集选票请求超时时间（初始） |
| zookeeper.fastleader.maxNotificationInterval |
60000（ms） |
收集选票请求超时时间（较大） |
| zookeeper.leader.maxTimeToWaitForEpoch |
-1 |
|
| zookeeper.leader.ackLoggingFrequency |
1000 |
|
| zookeeper.testingonly.initialZxid |
- |
初始化 zxid，仅供测试！ |
| zookeeper.leaderConnectDelayDuringRetryMs |
100 |
Leaner 连接 Leader 请求超时時间 |
| follower.nodelay |
true |
设置 TCP no delay |
| zookeeper.forceSnapshotSync |
false |
Learner 强制应用 snapshot 和 Leader 开展同歩 |
| zookeeper.leader.maxConcurrentSnapSyncs |
10 |
|
| zookeeper.leader.maxConcurrentDiffSyncs |
100 |
|
| zookeeper.observer.reconnectDelayMs |
0（ms） |
Observer 延迟重新连接至 Leader |
| zookeeper.observer.election.DelayMs |
200（ms） |
Observer 延迟逐渐选举 |
| zookeeper.observerMaster.sizeLimit |
32 * 1024 * 1024 |
|
| zookeeper.electionPortBindRetry |
3 |
选举端口连接重试次数 |
| zookeeper.tcpKeepAlive |
false |
Socket keep alive 设置 |
| zookeeper.cnxTimeout |
5000（ms） |
Socket 请求超时時间 |
| zookeeper.multiAddress.enabled |
false |
|
| zookeeper.multiAddress.reachabilityCheckTimeoutMs |
1000（ms） |
|
| zookeeper.multiAddress.reachabilityCheckEnabled |
true |
|
| zookeeper.quorumCnxnTimeoutMs |
-1 |
|
| zookeeper.observer.syncEnabled |
true |
Observer 是不是必须当地归档 |
| zookeeper.bitHashCacheSize |
10 |
位图初始缓存尺寸 |
| zookeeper.messageTracker.BufferSize |
10 |
|
| zookeeper.messageTracker.Enabled |
false |
|
| zookeeper.pathStats.slotCapacity |
60 |
|
| zookeeper.pathStats.slotDuration |
15 |
|
| zookeeper.pathStats.maxDepth |
6 |
|
| zookeeper.pathStats.sampleRate |
0.1 |
|
| zookeeper.pathStats.initialDelay |
5 |
|
| zookeeper.pathStats.delay |
5 |
|
| zookeeper.pathStats.topPathMax |
20 |
|
| zookeeper.pathStats.enabled |
false |
|
| zookeeper.watcherCleanThreshold |
1000 |
|
| zookeeper.watcherCleanIntervalInSeconds |
600 |
|
| zookeeper.watcherCleanThreadsNum |
2 |
|
| zookeeper.maxInProcessingDeadWatchers |
-1 |
|
| zookeeper.watchManagerName |
WatchManager（全路径） |
|
| zookeeper.connection_throttle_tokens |
0 |
|
| zookeeper.connection_throttle_fill_time |
1 |
|
| zookeeper.connection_throttle_fill_count |
1 |
|
| zookeeper.connection_throttle_freeze_time |
-1 |
|
| zookeeper.connection_throttle_drop_increase |
0.02 |
|
| zookeeper.connection_throttle_drop_decrease |
0.002 |
|
| zookeeper.connection_throttle_decrease_ratio |
0 |
|
| zookeeper.connection_throttle_weight_enabled |
false |
|
| zookeeper.connection_throttle_global_session_weight |
3 |
|
| zookeeper.connection_throttle_local_session_weight |
1 |
|
| zookeeper.connection_throttle_renew_session_weight |
2 |
|
| zookeeper.extendedTypesEnabled* |
false |
是不是启用 TTL 节点类型 |
| zookeeper.emulate353TTLNodes* |
false |
是不是兼容 3.5.3 的 TTL |
| zookeeper.client.portUnification |
false |
|
| zookeeper.netty.server.outstandingHandshake.limit |
-1 |
|
| zookeeper.netty.advancedFlowControl.enabled |
false |
|
| zookeeper.nio.sessionlessCnxnTimeout |
10000（ms） |
|
| zookeeper.nio.numSelectorThreads |
CPU 核心数 / 2 再开方 |
|
| zookeeper.nio.numWorkerThreads |
CPU 核心数 * 2 |
|
| zookeeper.nio.directBufferBytes |
64 * 1024（字节） |
|
| zookeeper.nio.shutdownTimeout |
5000（ms） |
|
| zookeeper.request_stale_connection_check |
true |
|
| zookeeper.request_stale_latency_check |
false |
|
| zookeeper.request_throttler.shutdownTimeout |
10000（ms） |
|
| zookeeper.request_throttle_max_requests |
0 |
|
| zookeeper.request_throttle_stall_time |
100 |
|
| zookeeper.request_throttle_drop_stale |
true |
|
| zookeeper.serverCnxnFactory |
NIOServerCnxnFactory（全路径） |
|
| zookeeper.maxCnxns |
0 |
|
| zookeeper.snapshotSizeFactor |
0.33 |
|
| zookeeper.commitLogCount |
500 |
|
| zookeeper.sasl.serverconfig |
Server |
|
| zookeeper.globalOutstandingLimit |
1000 |
|
| zookeeper.enableEagerACLCheck |
false |
|
| zookeeper.skipACL |
no |
|
| zookeeper.allowSaslFailedClients |
false |
|
| zookeeper.sessionRequireClientSASLAuth |
false |
|
| zookeeper.digest.enabled |
true |
|
| zookeeper.closeSessionTxn.enabled |
true |
|
| zookeeper.flushDelay |
0 |
|
| zookeeper.maxWriteQueuePollTime |
zookeeper.flushDelay / 3 |
|
| zookeeper.maxBatchSize |
1000 |
|
| zookeeper.intBufferStartingSizeBytes |
1024 |
|
| zookeeper.maxResponseCacheSize |
400 |
|
| zookeeper.maxGetChildrenResponseCacheSize |
400 |
|
| zookeeper.snapCount |
100000 |
|
| zookeeper.snapSizeLimitInKb |
4194304（千字节） |
|
| zookeeper.largeRequestMaxBytes |
100 * 1024 * 1024 |
|
| zookeeper.largeRequestThreshold |
-1 |
|
| zookeeper.superUser |
- |
|
| zookeeper.audit.enable |
false |
是不是开启 audit 日志 |
| zookeeper.audit.impl.class |
Log4jAuditLogger（全途径） |
audit 日志作用完成类 |
ZK 的配置或是许多的，有一些我这里 TODO 了，之后还有机会和大伙儿介绍下～并且非常一部分的配置 ZK 官方网的文档中早已列出了表述，可以查询 ZK 3.6.2 配置文档。
我这里还需要调侃下，ZK 中有一些配置是用 true 或是 false，有一些应用 yes 或是 no，显著是2个(波)人研发的，这类不应该做一个统一吗?yes 或 no 确实许多余...