ZooKeeper 概述以及集群的搭建

1. Zookeeper

1.1. ZooKeeper 概述

Zookeeper 是一个分布式协调服务的开源框架。主要用来解决分布式集群中
应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系
统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。诸如：统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

1.2. ZooKeeper 特性

1. 全局数据一致：每个 server 保存一份相同的数据副本，client 无论连
   接到哪个 server，展示的数据都是一致的，这是最重要的特征；
2. 可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。
3. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息 a 在消息 b 前发布，则在所有 Server 上消息 a 都将在消息 b 前被发布；偏序是指如果一个消息 b 在消息 a 后被同一个发送者发布，a 必将排在 b 前面。
4. 数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；
5. 实时性：Zookeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

1.3. ZooKeeper 集群角色

Leader:
Zookeeper 集群工作的核心
事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。
对于 create，setData，delete 等有写操作的请求，则需要统一转发给leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。

Follower:
处理客户端非事务（读操作）请求，转发事务请求给 Leader； 参与集群 Leader 选举投票。

Observer:
观察者角色，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader 服务器进行处理。
不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

1.4. ZooKeeper 集群搭建

Zookeeper 集群搭建指的是 ZooKeeper 分布式模式安装。通常由 2n+1
台 servers 组成。这是因为为了保证 Leader 选举（基于 Paxos 算法的实现）能过得到多数的支持，所以 ZooKeeper 集群的数量一般为奇数。

此次ZK集群将搭建在mini1、mini2、mini3三台虚拟机上，安装的版本为zookeeper-3.4.5.tar.gz

1. 安装jdk并配置好环境变量
2. 配置主机名称到 IP 地址映射配置 : 分别在三台虚拟机上 vim /etc/hosts 将主机名称和对应的IP地址写入该文件并保存。如下面是我的机器上的IP地址：

192.168.175.133   mini1
192.168.175.139   mini2
192.168.175.134   mini3

3. 在mini1、mini2、mini3 三台虚拟机上新建mini用户，并配置mini1到mini2、mini1到mini3的免密登录

# 配置免密登录
## 假设A要登录B  首先生成密钥对
ssh-keygen  (提示时，直接回车即可)
## 再将A自己的公钥拷贝并追加到B的授权列表文件authorized_keys中
ssh-copy-id  主机名

4. 将安装包上传到mini1的服务器上的/home/mini目录，并解压然后将文件zookeeper-3.4.5的名称修改为zookeeper

tar -zxvf zookeeper-3.4.5.tar.gz（解压）
mv zookeeper-3.4.5 zookeeper

5. 修改环境变量(可选)

1、su – root(切换用户到root)
2、vi /etc/profile(修改文件)
3、添加内容：
export ZOOKEEPER_HOME=/home/mini/zookeeper
export PATH=$PATH:$ZOOKEEPER_HOME/bin
4、重新执行文件：
source /etc/profile
5、注意：3台zookeeper都需要修改
6、修改完成后切换回mini用户：
su - mini

6. 修改配置文件

1、用mini用户操作
cd zookeeper/conf
cp zoo_sample.cfg zoo.cfg
2、vi zoo.cfg
3、修改成以下内容：
	# 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=/home/mini/zookeeper/data
	
	dataLogDir=/home/mini/zookeeper/log
	
	maxClientCnxns=0
	
	minSessionTimeout=4000
	maxSessionTimeout=10000
	
	# the port at which the clients will connect
	clientPort=2181
	#在之前设置的dataDir中新建myid文件, 写入一个数字, 该数字表示这是第几号server. 该数字必须和zoo.cfg文件中的server.X中的X一一对应.
	server.1=mini1:2888:3888
	server.2=mini2:2888:3888
	server.3=mini3:2888:3888
4、创建文件夹：
    cd /home/mini/zookeeper/
	mkdir -m 755 data
	mkdir -m 755 log
5、在data文件夹下新建myid文件，myid的文件内容为：
	cd data
	vi myid
添加内容：
      1

7. 将集群下发到其他机器上

scp -r /home/mini/zookeeper mini@mini2:/home/mini/
scp -r /home/mini/zookeeper minia@mini3:/home/mini/

8. 修改其他机器的配置文件
   到slave2上：修改myid为：2
   到slave3上：修改myid为：3

9. 启动（每台机器）

zkServer.sh start

2. ZooKeeper shell

2.1. 客户端连接

运行 zkCli.sh –server ip 进入命令行工具。

[mini@mini1 bin]$ ./zkCli.sh -server mini1:2181
Connecting to mini1

2.2. shell 基本操作

1. 创建节点
   create [-s] [-e] path data acl
   其中，-s 或-e 分别指定节点特性，顺序或临时节点，若不指定，则表示持久节点；acl 用来进行权限控制。
   创建顺序节点：
   
   创建临时节点：
   
   创建永久节点：
   

2. 读取节点
   与读取相关的命令有 ls 命令和 get 命令，ls 命令可以列出 Zookeeper 指
   定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点；get 命令可以获取 Zookeeper 指定节点的数据内容和属性信息。
   ls path [watch]
   get path [watch]
   ls2 path [watch]
   

3. 更新节点
   set path data [version]
   data 就是要更新的新内容，version 表示数据版本。
   
   现在 dataVersion 已经变为 1 了，表示进行了更新。

4. 删除节点
   delete path [version]
   若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。
   Rmr path : 可以递归删除节点。

5. quota
   setquota -n|-b val path 对节点增加限制。
   n:表示子节点的最大个数b:表示数据值的最大长度
   val:子节点最大个数或数据值的最大长度path:节点路径
   
   listquota path 列出指定节点的 quota
   
   子节点个数为 2,数据长度-1 表示没限制delquota [-n|-b] path 删除 quota

6. 其他命令
   history : 列出命令历史
   redo：该命令可以重新执行指定命令编号的历史命令,命令编号可以通过history 查看

3.Zookeeper中数据结构

3.1. 数据结构图

图中的每个节点称为一个 Znode。 每个 Znode 由 3 部分组成:
① stat：此为状态信息, 描述该 Znode 的版本, 权限等信息
② data：与该 Znode 关联的数据
③ children：该 Znode 下的子节点

3.2. 节点类型

Znode 有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。

1. 临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。
2. 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
3. Znode 还有一个序列化的特性，如果创建的时候指定的话，该 Znode 的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10 位数字， 没有数值的数位用 0 补充，例如“0000000001”)。
   
   这样便会存在四种类型的 Znode 节点，分别对应：
   PERSISTENT： 永 久 节 点 EPHEMERAL：临时节点PERSISTENT_SEQUENTIAL：永久节点、序列化EPHEMERAL_SEQUENTIAL：临时节点、序列化

3.3. 节点属性

每个 znode 都包含了一系列的属性，通过命令 get，可以获得节点的属性。

• dataVersion：数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加 1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
• cversion ：子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1。
• aclVersion ：ACL 的版本号。cZxid ：Znode 创建的事务 id。
• mZxid ：Znode 被修改的事务 id，即每次对 znode 的修改都会更新mZxid。 对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeper Transaction Id）。通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的 znode。ctime：节点创建时的时间戳.
  mtime：节点最新一次更新发生时的时间戳.
• ephemeralOwner:如果该节点为临时节点, ephemeralOwner 值表示与该节点绑定的 session id. 如果不是, ephemeralOwner 值为 0. 在 client 和 server 通信之前,首先需要建立连接,该连接称为 session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于 CLOSED 状态, 此时 session 结束。

4. ZooKeeper Watcher

ZooKeeper 提供了分布式数据发布/订阅功能，一个典型的发布/订阅模型系
统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。 ZooKeeper 中， 引入了 Watcher 机制来实现这种分布式的通知功能。 ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。 触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。总的来说可以概括 Watcher 为以下三个过程：客户端向服务端注册 Watcher、服务端事件发生触发 Watcher、客户端回调 Watcher 得到触发事件情况 。

4.1. Watch 机制特点

1. 一次性触发
   事件发生触发监听，一个 watcher event 就会被发送到设置监听的客户端， 这种效果是一次性的，后续再次发生同样的事件，不会再次触发。
2. 事件封装
   ZooKeeper 使用 WatchedEvent 对象来封装服务端事件并传递。WatchedEvent 包含了每一个事件的三个基本属性：
   通知状态（keeperState），事件类型（EventType）和节点路径（path）
3. event 异步发送
   watcher 的通知事件从服务端发送到客户端是异步的。
4. 先注册再触发
   Zookeeper 中的 watch 机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

4.2. 通知状态和事件类型

同一个事件类型在不同的通知状态中代表的含义有所不同，下表列举了常见的通知状态和事件类型。

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

其中连接状态事件(type=None, path=null)不需要客户端注册，客户端只要有需要直接处理就行了。

4.3. Shell 客户端设置 watcher

设置节点数据变动监听：

通过另一个客户端更改节点数据：

此时设置监听的节点收到通知：