Zookeeper

ZAB（Zookeeper Atomic Broadcast）协议是为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议

概念

ZAB是Zookeeper实现分布式数据一致性的核心算法，ZAB借鉴Paxos算法

在zookeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，zookeeper是实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

注意

ZAB协议的三个阶段【发现，同步，广播】

说明

即要求zookeeper集群必须选择出一个 leader 进程，同时 leader 会维护一个 follower 可用于列表。

将来客户端可以这 follower 中的节点进行通信

发现

leader 要负责将本身的数据于 follower 完成同步，做到多副本存储。体现了CAP中的CP。

follower 将队列中未处理完的请求消费完成后，写入本地事务日志中。

同步

leader 可以接收客户端新的 proposal 请求，将新的 proposal 请求广播给所有的 follower。

广播

分别

三个阶段

定义了对于那些会改变 Zookeeper 服务器数据状态的事务请求处理方式

核心

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为 Leader 服务器，而余下的其他服务器称为 Follower 服务器。

1、Leader 服务器负责将一个客户端事务请求转换成一个事务 Proposal（提议）

2、并将该 Proposal 分发给集群中所有的Follower 服务器。

3、之后 Leader 服务器需要等待所有的 Follower 服务器的反馈

4、一旦超过半数的 Follower 服务器进行了正确的反馈后

5、那么 Leader 就会再次向所有的 Follower 服务器分发 Commit 消息，要求将其前一个 Proposal 进行提交。

流程

协议核心

当整个集群正在启动时，或者当leader节点出现网络中断、崩溃等情况时

主节点崩溃

ZAB协议就会进入恢复模式并选举产生新的leader

重选主节点

当leader服务器选举出来后，并且集群中有过半的机器和该leader节点完成数据同步后（同步指的是数据同步，用来保证集群中过半的机器能够和leader服务器的数据状态保持一致），ZAB协议就会退出恢复模式。

数据同步保证一致性（C）

崩溃恢复之数据恢复

当集群中已经有过半的Follower节点完成了和Leader状态同步以后，那么整个集群就进入了消息广播模式。

消息广播模式

这个时候，在Leader节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入数据恢复模式，和leader节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理。

数据恢复模式

消息广播之原子广播

ZAB协议包含两种基本模式

ZAB协议用途

分支主题

图解

集群中所有修改数据的指令必须由总统发出

总统是由议员投票产生的（无主 --> 有主）

首先按照事务 zxid 进行排序

如果事务相同按照myid排序

选举条件

小岛——ZK Server Cluster

总统——ZK Server Leader

查询直接返回结果（有可能数据不一致）

发送消息给总统，总统将修改数据的命令发送给其他server

其他server接受命令后开始修改数据，修改完成后给总统返回成功的消息

当总统发现超过半数的人都修改成功了，就认为修改成功了

并将信息传递给接收请求的zkServer，zkServer将消息返回给客户端，说明数据更新完成

写入数据，先将数据写入到当前 server

接收客户端请求

拥有选举权，拥有投票权

接收客户端的访问

如果客户端执行写请求，只是将请求转发给 Leader

Follower

只可以为客户端提供数据的查询和访问

Observer

分类 Learner

议员(Senator)——ZK Server Learner

客户端的提议会被封装成一个Zookeeper维护的目录树上面

我们可以对数据进行访问（绝对路径）

数据量不能超过 1M

提议(Proposal)——ZNode Change

会按照数字序列递增，不会减少不会重复

提议编号(PID)——Zxid

超过半数的服务器更新这个数据，就说明数据已经是正式的了

正式法令——所有ZNode及其数据

发送请求（查询请求，修改请求）

屁民--Client

角色分配

Zookeeper角色分配

1、首先配置三台虚拟机相互免秘钥

[root@node01 ~]# tar -zxvf zookeeper-3.4.5.tar.gz [root@node01 ~]# mv zookeeper-3.4.5 /opt/soft/

[root@node01 conf]# cd /opt/soft/zookeeper-3.4.5/conf/ [root@node01 conf]# cp zoo_sample.cfg zoo.cfg[root@node01 conf]# vim zoo.cfg

命令

# #总共有三处需要注意 1数据存放路径 2客户端访问端口 3服务器集群节点 # the directory where the snapshot is stored. dataDir=/var/soft/zookeeper # the port at which the clients will connect clientPort=2181 # 设置服务器内部通信的地址和zk集群的节点 server.1=node01:2888:3888 server.2=node02:2888:3888 server.3=node03:2888:3888

内容

3、修改配置文件

[root@node01 conf]# vim /opt/soft/zookeeper-3.4.5/bin/zkEnv.sh

（1）$ZOOKEEPER_HOME/bin/zkEnv.sh

[root@node01 conf]# vim /opt/soft/zookeeper- 3.4.5/conf/log4j.properties

（2）$ZOOKEEPER_HOME/conf/log4j.properties

4、修改日志路径(选做)

[root@node02 soft]scp -r root@node01:/opt/soft/zookeeper-3.4.5 /opt/soft/ [root@node03 soft]scp -r root@node01:/opt/soft/zookeeper-3.4.5 /opt/soft/

5、拷贝Zookeeper

mkdir -p /var/soft/zookeeper

touch /var/soft/zookeeper/myid

（1）所有节点

[root@node01 soft]echo 1 > /var/soft/zookeeper/myid [root@node02 soft]echo 2 > /var/soft/zookeeper/myid [root@node03 soft]echo 3 > /var/soft/zookeeper/myid

（2）单个节点

6、创建myid

vim /etc/profile

export ZOOKEEPER_HOME=/opt/soft/zookeeper-3.4.5 export PATH=$ZOOKEEPER_HOME/bin:$PATH

所有节点设置

source /etc/profile

生效环境变量

7、设置环境变量

zkServer.sh start

开启

zkServer.sh status

状态

zkServer.sh stop

关闭

所有节点

8、开启集群

搭建Zookeeper

启动ZK服务: bin/zkServer.sh start

查看ZK服务状态: bin/zkServer.sh status

停止ZK服务: bin/zkServer.sh stop

重启ZK服务: bin/zkServer.sh restart

连接服务器: zkCli.sh -server 127.0.0.1:2181

1、zk服务命令

zkCli.sh -server 127.0.0.1:2181

2、连接zk

[zk: 127.0.0.1:2181(CONNECTED) 1] ls / ls /path

例如

ls -- 查看某个目录包含的所有文件

与ls不同的是它查看到time、version等信息

描述

[zk: 127.0.0.1:2181(CONNECTED) 1] ls2 /

ls2 -- 查看某个目录包含的所有文件

[zk: 127.0.0.1:2181(CONNECTED) 1] create /test "test“Created /test

create /path data

默认创建持久化节点

create -s /path data

-s：创建顺序节点

create -e /path data

-e：创建临时节点

create /parent/sub/path /data

参数

create -- 创建znode，并设置初始内容

[zk: 127.0.0.1:2181(CONNECTED) 1] get /test

get /path0000000018 访问顺序节点必须输入完整路径

get -- 获取znode的数据

[zk: 127.0.0.1:2181(CONNECTED) 1] set /test "ricky"

set -- 修改znode内容

[zk: 127.0.0.1:2181(CONNECTED) 1] delete /test

delete /path 删除没有子节点的节点

rmr /path 移除节点并且递归移除所有子节点

delete -- 删除znode

quit -- 退出客户端

help -- 帮助命令

3、zk客户端命令

Zookeeper命令

zookeeper是一个树状结构，维护一个小型的数据节点znode

数据以keyvalue的方式存在，目录是数据的key

所有的数据访问都必须以绝对路径的方式呈现

get 输出参数详解

存储结构

默认创建的就是持久化节点

持久化节点（PERSISTENT）

只要创建节点的会话有效，节点就不会失效

可以被所有的客户端所查看

事务编号和临时节点编号是一致的

create -e

一旦会话结束，临时节点也会被自动删除，一般这个功能用于判断节点和服务器是否保持连接

临时节点（Ephemral）

在名字的后面添加一个序列号（有序）

序列化节点（Sequential）

节点分类

Zookeeper存储模型

一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，一边通知他们

官方说明

一次性触发，数据发生改变时，一个 watcher event 会被发送到 client，但是 client 只会收到一次这样的信息

watcher event 异步发送

机制特点

Zookeeper 有数据监视和子数据监视 getdata() and exists() 设置数据监视，get children() 设置了子节点监视

watch监听有不同的类型，有监听状态的stat ，内容的get，目录结构的ls。

NodeDataChanged

get /path [watch]

NodeDeleted

stat /path [watch]

NodeChildrenChanged

ls /path [watch]

创建父节点触发: NodeCreated

修改父节点数据触发: NodeDataChanged

删除父节点触发: NodeDeleted

父节点Watcher事件类型:

子节点Watcher事件类型:

数据监视

ZKServer的监听机制

CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限， 这5种权限简写为crwda

这5种权限中，delete是指对子节点的删除权限，其它4种权限指对自身节点的操作 权限

zk节点的五种操作权限

默认方式，相当于全世界都能访问

world

代表已经认证通过的用户

cli中可以通过addauth digest user:pwd 来添加当前上下文中的授 权用户

auth

即用户名:密码这种方式认证，这也是业务系统中最常用的

digest

使用Ip地址认证

ip

身份的认证有4种方式

ip：使用IP地址认证

auth：使用已添加认证的用户认证

digest：使用用户名：密码 方式认证

schema

world:只有一个id，anyone

ip：通常是一个ip地址或者地址段

auth:用户名

digest：自定义

id

delete 简写为d 可以删除子节点

read 简写为r 可以读取节点数据及显示子节点列表

write 简写为w 可以设置节点数据

admin 简写为a 可以设置管理权限

权限

getAcl /parent

查看ACL

setAcl /parent world:anyone:r

设置ACL

addauth digest zhangsan:123456

addauth digest lisi:123456

添加用户

setAcl /parent auth:zhangsan:123456:r

setAcl /parent auth:lisi:123456:rcwd

设置权限

quit

退出当前用户

addauth digest zhangsan:123456

后续访问 /parent路径，需要先添加用户

ACL权限控制（了解）

ZooKeeper 支持某些特定的四字命令(The Four Letter Words)与其进行交互。

在shell终端输入：echo 四字命令| nc node01 2181

使用方式

四字命令（了解）

pom.xml

封装工具类

测试类

Java访问Zookeeper（了解）

有一组服务器向客户端提供某种服务，我们希望客户端每次请求服务端都可以找到服务端集群中某一台服务器，这样服务端就可以向客户端提供客户端所需的服务。对于这种场景，我们的程序中一定有一份这组服务器的列表，每次客户端请求时候，都是从这份列表里读取这份服务器列表。那么这分列表显然不能存储在一台单节点的服务器上，否则这个节点挂掉了，整个集群都会发生故障，我们希望这份列表时高可用的。高可用的解决方案是：这份列表是分布式存储的，它是由存储这份列表的服务器共同管理的，如果存储列表里的某台服务器坏掉了，其他服务器马上可以替代坏掉的服务器，并且可以把坏掉的服务器从列表里删除掉，让故障服务器退出整个集群的运行，而这一切的操作又不会由故障的服务器来操作，而是集群里正常的服务器来完成。这是一种主动的分布式数据结构，能够在外部情况发生变化时候主动修改数据项状态的数据机构。，它和javaEE里的JNDI服务很像。

场景一：统一命名服务

当分布式系统操作数据，例如：读取数据、分析数据、最后修改数据。在分布式系统里这些操作可能会分散到集群里不同的节点上，那么这时候就存在数据操作过程中一致性的问题，如果不一致，我们将会得到一个错误的运算结果，在单一进程的程序里，一致性的问题很好解决，但是到了分布式系统就比较困难，因为分布式系统里不同服务器的运算都是在独立的进程里，运算的中间结果和过程还要通过网络进行传递，那么想做到数据操作一致性要困难的多。

Zookeeper提供了一个锁服务解决了这样的问题，能让我们在做分布式数据运算时候，保证数据操作的一致性。

场景二：分布式锁服务

在分布式系统里，我们会把一个服务应用分别部署到n台服务器上，这些服务器的配置文件是相同的（例如：我设计的分布式网站框架里，服务端就有4台服务器，4台服务器上的程序都是一样，配置文件都是一样），如果配置文件的配置选项发生变化，那么我们就得一个个去改这些配置文件，如果我们需要改的服务器比较少，这些操作还不是太麻烦，如果我们分布式的服务器特别多，比如某些大型互联网公司的hadoop集群有数千台服务器，那么更改配置选项就是一件麻烦而且危险的事情。这时候zookeeper就可以派上用场了，我们可以把zookeeper当成一个高可用的配置存储器，把这样的事情交给zookeeper进行管理，我们将集群的配置文件拷贝到zookeeper的文件系统的某个节点上，然后用zookeeper监控所有分布式系统里配置文件的状态，一旦发现有配置文件发生了变化，每台服务器都会收到zookeeper的通知，让每台服务器同步zookeeper里的配置文件，zookeeper服务也会保证同步操作原子性，确保每个服务器的配置文件都能被正确的更新。

场景三：配置管理。

集群管理是很困难的，在分布式系统里加入了zookeeper服务，能让我们很容易的对集群进行管理。集群管理最麻烦的事情就是节点故障管理，zookeeper可以让集群选出一个健康的节点作为master，master节点会知道当前集群的每台服务器的运行状况，一旦某个节点发生故障，master会把这个情况通知给集群其他服务器，从而重新分配不同节点的计算任务。Zookeeper不仅可以发现故障，也会对有故障的服务器进行甄别，看故障服务器是什么样的故障，如果该故障可以修复，zookeeper可以自动修复或者告诉系统管理员错误的原因让管理员迅速定位问题，修复节点的故障。大家也许还会有个疑问，master故障了，那怎么办了？zookeeper也考虑到了这点，zookeeper内部有一个“选举领导者的算法”，master可以动态选择，当master故障时候，zookeeper能马上选出新的master对集群进行管理。

场景四：为分布式系统提供故障修复的功能

分布式协调框架

基于Observer的环境搭建

Zookeeper的热部署

Zookeeper环境搭建（了解）

Zookeeper