1. 搭建

版本：3.7
github clone 下来之后用 IDEA 打开，maven clean install

服务端 debug 配置：

客户端 debug 配置

1. 概述

Zookeeper 使用⼀个单⼀的主进程来接收并处理客户端的所有事务请求

并采用 ZAB （ Zookeeper Atomic Broadcast，原子广播协议），将服务器数据的状态变更以事务 Proposal 的形式广播到所有的副本进程中

读写请求官方压测：

3888 端口通信模型：
任何两个节点都互通

1. 事务 Id

概述：

• 变更状态： 事务是指能够改变 ZooKeeper 服务器状态的操作，我们也称之为事务操作或更新操作。⼀般包括数据节点创建与删除、数据节点内容更新等操作。
• ZXID： 对于每⼀个事务请求（proposal 提议），ZooKeeper 都会为其分配⼀个全局唯⼀（zk 中唯一）且有序的事务 ID，用 ZXID 来表示，通常是⼀个 64 位的数字。
  • 高 32 位是 epoch（投票轮次），用来标识 Leader 是否发生改变。从 1 开始，如果有新的 Leader 产生出来，epoch 会自增。
  • 低 32 位用来递增计数。每次 epoch 变化，都将低 32 位的序号重置。

作用： 标识节点同步状态。

1. 数据发布 / 订阅

1.1. 概述

即所谓的配置中⼼，顾名思义就是发布者将数据发布到 ZooKeeper 的⼀个或⼀系列节点上，供订阅者进⾏数据订阅，进⽽达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。

两种设计模式：

• 推（Push）模式：服务端主动将数据更新发送给所有订阅的客户端
• 拉（Pull）模式：由客户端主动发起请求来获取最新数据，通常客户端都采⽤定时进⾏轮询拉取的⽅式
• ZooKeeper 采⽤的是推拉相结合的⽅式：
  • 客户端向服务端注册⾃⼰需要关注的节点，⼀旦该节点的数据 发⽣变更，那么服务端就会向相应的客户端发送 Watcher 事件通知。
  • 客户端接收到这个消息通知之后， 需要主动到服务端获取最新的数据。

zk 有 Session，没有线程池的概念

1. 原生 API

Zookeeper API 共包含五个包：

• org.apache.zookeeper
• org.apache.zookeeper.data
• org.apache.zookeeper.server
• org.apache.zookeeper.server.quorum
• org.apache.zookeeper.server.upgrade

依赖：

1
2
3
4

<dependency> <groupId>org.apache.zookeeper</groupId> 
    <artifactId>zookeeper</artifactId> 
    <version>3.4.14</version>
</dependency>

安装 nc： yum install nc
命令格式： echo [commond] | nc [ip] [port]
stat： 查看 zk 的状态信息

1
2
3
4
5
6
7
8
9
10
11
12

[root@izbp101vzs716yznuegsljz bin]# echo stat | nc localhost 2181
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMTClients:
/127.0.0.1:55394 [0] (queued-0, recved=1, sent=0)

Latency min/avg/max: 0/0/0
Received: 2
Sent: 1
Connections: 1
Outatanding: 0
Zxid: 0xed
Mode: standalone
Node count: 29

1. ACL 构成

概述： 针对节点可以设置相关读写权限，保障数据安全

通过 scheme:id:permissions 来构成权限列表

• scheme：         代表采用的某种权限机制
• id：                   代表允许访问的用户
• permissions： 代表允许的操作权限

例： setAcl path world:anyone:d 代表为 path 下的节点设置权限为所有人都只能删除该节点

1.1. scheme 类型

• world（world:anyone:[permissions]）：                                                     默认权限。只有一个用户 —— anyone
• auth（auth:user:password:[permissions]）：                                            代表认证登录，需要注册用户拥有权限
• digest（digest:username:BASE64(SHA1(password)):[permissions]）： 需要对密码加密才能访问
• ip（ip:192.168.1.1:[permissions]）：                                                            限制 ip 进行访问
• super：                                                                                                             超级管理员，拥有所有权限

1.2. permissions

crdwa 代表的权限含义：

• CREATE： 创建 子节点
• READ：     读取节点数据
• WRITE：    往节点写入数据
• DELETE： 删除 子节点，对于 delete 权限，要谨慎规划
• ADMIN：   可以使用 setAcl 命令设置权限

概述： 为一个节点注册监听器，在节点状态发生改变时，会给客户端发送消息。

1. 特性

• 一次性： watcher 触发后立即销毁。
• 轻量级： watch 是轻量级的，其实就是本地 JVM 的 Callback，服务器端只是存了是否有设置了 watcher 的布尔类型
• 可见性： Watch 被触发的同时再次读取数据，客户端会得到 Watch 消息再看到更新后的数据。
• 可能会丢失： 对于一个未创建的 znode 的 exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个 Watch 事件可能会被丢失。

1. ls path [watch]

查看某个路径下有多少个节点

1
2
3
4

[zk: localhost:2181(CONNECTED) 2] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 3] ls /zookeeper
[quota]

1. 概述

ZooKeeper 是一个分布式协调中间件，是 Google 的 Chubby 一个开源的实现。它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

特性：

• 顺序一致性： 客户端的更新将按顺序执行。因其写操作完全由单一 Leader 节点来执行（事务 id）
• 原子性：         操作要么成功要么失败（事务）
• 单一视图：     无论连接到哪个节点，客户端都能看到相同的视图。（恢复模式 + 广播模式）
• 及时性：         在特定时间范围内的数据是最新的。由最终一致性保证，同步需一定时间（数据同步）
• 可靠性：
  • 数据不会丢失。zk 是将数据存储到内存中的，所以肯定会有持久化（日志 + 快照）
  • 快速恢复 Leader。恢复模式（选主 + 数据同步）