ZooKeeper <二> 安装使用

ZooKeeper version： 3.6.0

安装

本示例均在 CentOS Linux release 8.1.1911 (Core) 下进行

同时需要保证当前机器含有 java 环境，java 安装步骤可参考 这里

1. 下载

首先到 Apache Download 寻找合适的版本，这里以 3.6.0 为例，下载

wget 

2. 解压

tar -xvf apache-zookeeper-3.6.0-bin.tar.gz

3. 单机版启动

如图示，我在解压完后，将那串长长的目录名，重命名为 zk1， 同时又 cp 了 zk2 和 zk3，cp zoo_sample.cfg 为 zoo.cfg

# 修改名称mv apache-zookeeper-3.6.0-bin zk1# cp 两份，为后面的伪集群搭建做准备cp -r zk1 zk2 cp -r zk1 zk3# 增加 zoo.cfg 配置cd zk1 &&  cp conf/zoo_sample.cfg zoo.cfg

这里我没有修改任何地方，直接 start

./bin/zkServer.sh start/usr/bin/javaZooKeeper JMX enabled by defaultUsing config: /home/dylan/tmp/zookeeper/zk1/bin/../conf/zoo.cfgStarting zookeeper ... STARTED

可以看到， zk1 已经启动，我们验证一下：

./bin/zkServer.sh status/usr/bin/javaZooKeeper JMX enabled by defaultUsing config: /home/dylan/tmp/zookeeper/zk1/bin/../conf/zoo.cfgClient port found: 2181. Client address: localhost.Mode: standalone

通过 zkServer.sh status ，能看到 zk 已经正常启动，Mode 为 standalone ，当我们配置 ensemble 时，这个 Mode 就会变成 Leader/Follower/Observer

4. 单机伪集群版

前面我们已经 cp 了 3 个 zk，现在我们再添加一个 observer 节点，同时，在各个 dataDir 新建 myid 文件，并写入值，如 zk1 的 dataDir 为 /tmp/zk1 ，则我们执行： echo 1 > /tmp/zk1/myid

4.1 四份配置如下：

其中涉及到的配置项有：

tickTime：zk 中的计时单元，单位毫秒(milliseconds)，心跳间隔，session timeout = 2倍 tickTime(默认)initLimit：ensemble 初始化时，server(Follower/Observer) 与 Leader 进行连接的最大时长，超过该时间如果还未连接成功，则宣告连接失败。对于 Follower 而言，则是连接并同步到 Leader 的时间。如果 zookeeper 集群管理的数据量很大，则根据需要增加这个值syncLimit： 同步时间，如果 Follower 在 syncLimit 时间内未完成同步，则将被 Leader 丢弃dataDir：zk 用于存放数据的地方，myid 文件也存放在这个地方。zk 官方建议该目录应该是一个专门为 zk 事务日志准备的目录：

To get low latencies on updates it is important to have a dedicated transaction log directory. By default transaction logs are put in the same directory as the data snapshots and myid file. The dataLogDir parameters indicates a different directory to use for the transaction logs.

clientPort： 监听客户端连接的端口。如果你的客户端使用的不是这个端口，那这里就要改了。这里因为在同一台机器上，所以改成了不同的端口peerType：配置了 peerType=observer 的 server，将成为 observer，本例中的 zk4 将成为 observerobserverMasterPort： 默认情况下， Observer 从 Leader 获得新 proposal， 启用该配置后，observer 将从 Follower 获得 proposal。Follower 将会监听该端口。这样做的好处是，能减轻 Leader 的压力。我上面配置的值不相同，是因为我在单机上，如果配置相同，会出现端口冲突，实际这里应该是同一个端口。

By default, Observers connect to the Leader of the quorum along its quorum port and this is how they learn of all new proposals on the ensemble. There are benefits to allowing Observers to connect to the Followers instead as a means of plugging into the commit stream in place of connecting to the Leader. It shifts the burden of supporting Observers off the Leader and allow it to focus on coordinating the commit of writes. This means better performance when the Leader is under high load, particularly high network load such as can happen after a leader election when many Learners need to sync. It reduces the total network connections maintained on the Leader when there are a high number of observers. Activating Followers to support Observers allow the overall number of Observers to scale into the hundreds. On the other end, Observer availability is improved since it will take shorter time for a high number of Observers to finish syncing and start serving client traffic.

server.1=127.0.0.1:2284:3884:observer ： 为方便介绍我们把这里改写成如下形式：server.myid=net:port1:port2:observer， 则myid： myid，需要与该 server dataDir 下 myid 文件中的值保持一致(这个文件需要我们手动创建)net： 该 server 的 hostport1：用于 peer 到 peer 的 TCP 通信， peer 即一个 zk server；以及和 Leader 之间的通信，这个端口，事实上，只有 server 成为 Leader 后才会去监听。虽然文档说是 peer to peer， 但仔细看下源码和实践，这个端口确实是 Leader 用来和各 server 通信用的port2： 选举期间，各个 server 之间的 TCP 通信端口，即选举使用的端口observer： 表明该 server 为 observer3.6.0 版本中，可以使用 multiple addresses ， 结构如下server.myid=net1:port1:port2|net2:port1:port2， 即通过分隔符( | )来分割不同的 addressleaderServes ：Leader 是否可以连接 client，默认为 true，为 false 时，表明 Leader 只需要专注于协同(coordination)。如果写请求远高于读请求，可以设置为 false。更多配置，请参考 这里 ， 这里 ，还有 这里

4.2 启动

分别执行(注意下执行目录)

./zk1/bin/zkServer.sh start

上面没有更改日志位置，所以可以在 ./zk1/logs 下面找到

当只启动了 zk1 时，日志如上所示，它在尝试和 zk2 ，zk3 通信时，会一直失败，当我们启动了 zk2 和 zk3 时，整个集群就会稳定下来。

因为单机版的问题，这里 zk4 ，即 observer 的 observerMasterPort 配置为 2481，即 zk1 ，所以如果 zk1 当选为 Leader ，此时 zk4 会疯狂刷日志，报 connection refused，别问我怎么知道的！！！

通过这张图我们可以看到 ，zk1 成功当选了 leader，则它监听的端口有：

3881：用于选举的端口，任何时候都会去监听2281：用于和其他 server 通信的端口，即前文的 port12481： 作为 leader，它已经不用去监听这个 observerMasterPort 了，所以这里我们看不到2181： 用于和客户端通信的端口，我们没有配置 leaderServes=false，所以 leader 还需要响应 client

Follower 监听的端口有(这里以 zk2 为例)：

3882：选举端口，时刻保持监听，万一 leader 挂了，选了我做 leader 呢！2482：observerMasterPort，负责和 observer 通信的 TCP 端口2182：和 client 交互的 TCP 端口

4.3 简单使用

# 不加[]中内容，默认连接到 2181 端口./zk1/bin/zkCli.sh [-server localhost:2182]​# 输入 help ，会打印出命令# 可以看到 create 相关: create [-s] [-e] [-c] [-t ttl] path [data] [acl]# 我们用 create 创建一个节点,其中 data 为 "zk_test_data"， acl 我们暂时不设置create /zk_test "zk_test_data"​# 通过 ls / 能到节点已经创建ls /​# get 获取节点信息, -s 参数会把整个节点信息 zxid 等打印出来get -s /zk_test​# 更多命令请百度/Google# 使用到此结束

ACL

ACL 有关的官方文档请点击 这里

所谓 ACL ，即 Access Control Lists ，访问控制列表。在 zk 中，用来控制访问 znode。

1. ACL 构成

<scheme>:<id>:<perms>

// org.apache.zookeeper.data.ACLpublic ACL(    int perms,    org.apache.zookeeper.data.Id id) {    this.perms=perms;    this.id=id;}// org.apache.zookeeper.data.Idpublic Id(    String scheme,    String id) {    this.scheme=scheme;    this.id=id;}// org.apache.zookeeper.ZooDefs.Perms public interface Perms {    int READ = 1 << 0;    int WRITE = 1 << 1;    int CREATE = 1 << 2;    int DELETE = 1 << 3;    int ADMIN = 1 << 4;    int ALL = READ | WRITE | CREATE | DELETE | ADMIN;}

通过源码我们可以看到, ACL = Id + perms 构成 , 而 Id = scheme + id

2. Perms

同样由源码可以看到 perms 主要包含以下几种:

readwritecreatedeleteadmin : you can set permissions , 毕竟是 admin,你可以胡作非为all： 所有权限3. 内置权限方案

zookeeper 内置的 scheme 有如下几种：

world： 即任何人都可以拥有你设置的权限，<world>:<anyone><perms>digest：<digets>:<username:password>:<perms> , 这里的 password， 是指 base64 编码的 sha1 密码摘要，填入 ACL 中。比如 username 为 dylan , 密码为 123456， 则进行如下操作： echo -n dylan:123456 | openssl dgst -binary -sha1 | openssl base64则最终 scheme 应该长这个样子： digest:dylan:7i6SL+m6GkW2OYpURnpkay0UdBc=:crwdaip：使用客户端主机 IP 作为 ACL ID 身份。 ACL 表达式的形式为 addr / bits，其中 addr 的最高有效位与客户端主机 IP 的最高有效位相匹配。如： ip:127.0.0.1/16:crwda 这里文档说最高有效位与 client 主机 ip 最高有效位要相匹配，不过我实际试了下，不匹配也没有关系，这里暂时存疑。auth： 无 id， 对所有已认证的用户开放。形如 auth::crwda ，这里即使设置了 id，也会被忽略掉！x509：使用 x509 证书进行 client 端验证，使用该方案时，需要在配置文件中配置如下选项 ，具体参见 这里zookeeper.ssl.keyStore.locationzookeeper.ssl.trustStore.locationzookeeper.ssl.keyStore.passwordzookeeper.ssl.trustStore.password

事实上，还有 sasl，你可以在 zoo.cfg 中进行配置：

authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider

以及 super ！！！

Watch

Watch 有关的官方文档请参考 这里

zk 的 watch 机制，也是我们 这篇文章 提到的很多应用的保证之一，正式因为 zk 的 watch 机制提供了这些保证，我们才能说，这样做，是可以的。

那么，zk 的 watch 机制究竟是什么？又提供了哪些保证呢？

zk watch event ，当 watch 的 数据发生变化时，watch event 会 一次触发 ，发送给设置了 watch event 的客户端。

one-time trigger ： 当设置的 watch event 被处罚时，触发且仅触发一次。当这个节点再次改变时，不会二次触发，除非再次设置 watch event(3.6 中已经增加了永久，永久递归类型的 watch)send to the client：watch event 会被异步的发送被 client，由于网络延迟等问题，会导致各个 client 收到 event 的时间差异， zk 保证 一个 client 永远不会在 watch event 到来前，观察到数据的变更，只有在 client 监听到 event 后，才能感知到数据的变化the data for which the watch was set：这里指 zk 不同的 watch event ，会产生不同的效果。这里下文会介绍到1. watch event type

我们在 org.apache.zookeeper.Watcher.Event.EventType 能看到， 3.6 版本总共有如下几种 watch event：

None：无 watchNodeCreated：通过 exists() 添加，当这个节点被创建后，发出 watch eventNodeDeleted：通过 exists , getData , getChildren 添加NodeDataChanged：exists 和 getData 添加NodeChildrenChanged： getChildren 添加DataWatchRemoved： exists 和 getData 添加ChildWatchRemoved：getChildren 添加PersistentWatchRemoved：persistent watch 添加， 3.6.0 中，专门有 addWatch 方法，该方法可以指定 watcher 类型，具体需要参考使用 zk client：PERSISTENT ： 持久 watch ，data change 和 children change 均会被触发PERSISTENT_RECURSIVE：持久递归 watch，会 watch 给定 path 的 children2. zookeeper guarantees about watcheszk(准确说是 zk client) 保证 watch event 的派发是有序的zk client 在收到 znode 的 watch event 之后才能看到该 znode 的新数据zk 中 watch event 的顺序与 zk 看到的更新顺序一致。即 zk 中的 watch event 顺序与 zk 的更新顺序相对应

基于 watch event 的特点，有两个地方需要特别注意：

如果你使用一次性的 watch event，则在再次 watch znode 的时候，你需要做好遗漏该 znode 可能出现的多次变更的情况。因为在你再次添加 watch event 的时候，这个 znode 可能已经被改变了好几次了。watch event 是 one-time trigger ， 也就是说，如果你既通过 exists 又通过 getData 设置了 watch event ，那么你最终只会获得一个 watch event 事件。

To Be ContinueFastLeaderElectionZab 协议详解部分源码解析watch 源码解析