一、概要、背景及作用
zookeeper产生背景
项目从单体到分布式转变之后,将会产生多个节点之间协同的问题。如
1、定时任务由哪个节点来执行
2、RPC调用时的服务与发现
3、如何实现分布式锁(保证并发请求的幂等性)
4、……
这些问题可以统一归纳为多节点协调问题,如果靠节点自身进行协调这是非常不可靠的,性能上也不可取。必须由一个独立的服务做协调工作,它必须可靠,而且保证性能
zookeeper概要
ZooKeeper是在分布式应用程序中提供协调服务的apache项目。它公开了一组简单的API,分布式应用程序可以基于这些API用于同步,节点状态、配置等信息、服务注册等信息。其由JAVA编写。
znode节点
zookeeper 中数据基本单元叫节点,节点之下可包含子节点,最后以树级方式程现。每个节点拥有唯一的路径path。客户端基于PATH上传节点数据,zookeeper 收到后会实时通知对该路径进行监听的客户端。
Zookeeper工作机制
Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者(客户端)的注 册,一旦这些数据的状态发生变化,Zookeeper就 将负责通知已经在Zookeeper上注册的那些观察者(客户端)做出相应的反应。

特点
1)Zookeeper:一个领导者(Leader),多个跟随者(Follower)组成的集群。
2)过半机制:集群中只要有半数以上节点存活,Zookeeper集群就能正常服务。所 以Zookeeper适合安装奇数台服务器
3)全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个Server,数据都是一致的。
4)更新请求顺序执行,来自同一个Client的更新请求按其发送顺序依次执行。
5)数据更新原子性,一次数据更新要么成功,要么失败。
6)实时性,在一定时间范围内,Client能读到最新数据.

应用场景
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等.
服务发现与注册(在dubbo中使用)


统一配置管理
1)分布式环境下,配置文件同步非常常见。
(1)一般要求一个集群中,所有节点的配置信息是一致的,比如 Kafka 集群。
(2)对配置文件修改后,希望能够快速同步到各个节点上。
2)配置管理可交由ZooKeeper实现。
(1)可将配置信息写入ZooKeeper上的一个Znode
(2)各个客户端服务器监听这个Znode。
(3)一 旦Znode中的数据被修改,ZooKeeper将通知各个客户端服务器。

软负载均衡
在Zookeeper中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请求

分布式锁
多节点系统定时任务
二、部署与常规配置
zookeeper 基于JAVA开发,下载后只要有对应JVM环境即可运行。其默认的端口号是2181运行前得保证其不冲突。
具体部署流程:
1 | |
配置文件修改:
1 | |
客户端命令
基本命令列表
close
关闭当前会话
connect host:port
重新连接指定Zookeeper服务
create [-s] [-e] [-c] [-t ttl] path [data] [acl]
创建节点
delete [-v version] path
删除节点,(不能存在子节点)
deleteall path
删除路径及所有子节点
setquota -n|-b val path
设置节点限额 -n 子节点数 -b 字节数
listquota path
查看节点限额
delquota [-n|-b] path
删除节点限额
get [-s] [-w] path
查看节点数据 -s 包含节点状态 -w 添加监听
getAcl [-s] path
ls [-s] [-w] [-R] path
列出子节点 -s状态 -R 递归查看所有子节点 -w 添加监听
printwatches on|off
是否打印监听事件
quit
退出客户端
history
查看执行的历史记录
redo cmdno
重复 执行命令,history 中命令编号确定
removewatches path [-c|-d|-a] [-l]
删除指定监听
set [-s] [-v version] path data
设置值
setAcl [-s] [-v version] [-R] path acl
为节点设置ACL权限
stat [-w] path
查看节点状态 -w 添加监听
sync path
强制同步节点
node数据的增删改查
1 | |
三、Zookeeper节点与原生API介绍
zookeeper 中节点叫znode存储结构上跟文件系统类似,以树级结构进行存储。不同之外在于znode没有目录的概念,不能执行类似cd之类的命令。znode结构包含如下:
- path:唯一路径
- childNode:子节点
- stat:状态属性
- type:节点类型
节点类型
| 类型 | 描述 |
|---|---|
| PERSISTENT(默认) | 持久节点 |
| PERSISTENT_SEQUENTIAL | 持久序号节点 |
| EPHEMERAL | 临时节点(不可在拥有子节点)-会话断开后删除 |
| EPHEMERAL_SEQUENTIAL | 临时序号节点(不可在拥有子节点) |
- PERSISTENT(持久节点)
持久化保存的节点,也是默认创建的
1 | |
- PERSISTENT_SEQUENTIAL(持久序号节点)
创建时zookeeper 会在路径上加上序号作为后缀,。非常适合用于分布式锁、分布式选举等场景。创建时添加 -s 参数即可。
1 | |
- EPHEMERAL(临时节点)
临时节点会在客户端会话断开后自动删除。适用于心跳,服务发现等场景。创建时添加参数-e 即可。
1 | |
- EPHEMERAL_SEQUENTIAL(临时序号节点)
与持久序号节点类似,不同之处在于EPHEMERAL_SEQUENTIAL是临时的会在会话断开后删除。创建时添加 -e -s
1 | |
节点属性
1 | |
其属性说明如下表:
1 | |
| cZxid | 创建节点的事物ID |
|---|---|
| mZxid | 最新一次修改节点的事物ID |
| pZxid | 子节点变更的事物ID |
| cversion | 这表示对此znode的子节点进行的更改次数(不包括子节点) |
| dataVersion | 数据版本,变更次数 |
| aclVersion | 权限版本,变更次数 |
ZXID是一个长度64位的数字,其中低32位是按照数字递增,任何数据的变更都会导致,低32位的数字简单加1。高32位是leader周期编号,每当选举出一个新的leader时,新的leader就从本地事物日志中取出ZXID,然后解析出高32位的周期编号,进行加1,再将低32位的全部设置为0。这样就保证了每次新选举的leader后,保证了ZXID的唯一性而且是保证递增的。
acl权限设置
ACL全称为Access Control List(访问控制列表),用于控制资源的访问权限。ZooKeeper使用ACL来控制对其znode的防问。基于scheme: id :permission的方式进行权限控制。scheme表示授权模式、id模式对应值、permission即具体的增删改权限位。
scheme:认证模型
| 方案 | 描述 |
|---|---|
| world | 开放模式,world表示全世界都可以访问(这是默认设置) |
| ip | ip模式,限定客户端IP防问 |
| auth | 用户密码认证模式,只有在会话中添加了认证才可以防问 |
| digest | 与auth类似,区别在于auth用明文密码,而digest 用sha-1+base64加密后的密码。在实际使用中digest 更常见。 |
permission权限位
| 权限位 | 权限 | 描述 |
|---|---|---|
| c | CREATE | 可以创建子节点 |
| d | DELETE | 可以删除子节点(仅下一级节点) |
| r | READ | 可以读取节点数据及显示子节点列表 |
| w | WRITE | 可以设置节点数据 |
| a | ADMIN | 可以设置节点访问控制列表权限 |
acl 相关命令:
| 命令 | 使用方式 | 描述 |
|---|---|---|
| getAcl | getAcl |
读取ACL权限 |
| setAcl | setAcl |
设置ACL权限 |
| addauth | addauth |
添加认证用户 |
world权限示例
语法: setAcl
注:world模式中anyone是唯一的值,表示所有人
- 查看默认节点权限:
1 | |
- 修改默认权限为 读写
1 | |
IP权限示例:
语法: setAcl
auth模式示例:
语法:
- setAcl
auth:<用户名>:<密码>:<权限位> - addauth digest <用户名>:<密码>
digest 权限示例:
语法:
- setAcl
digest :<用户名>:<密钥>:<权限位> - addauth digest <用户名>:<密码>
注1:密钥 通过sha1与base64组合加密码生成,可通过以下命令生成
1 | |
注2:为节点设置digest 权限后,访问前必须执行addauth,当前会话才可以防问。
- 设置digest 权限
1 | |
- 查看节点将显示没有权限
1 | |
- 给当前会话添加认证后在次查看
1 | |
ACL的特殊说明:
权限仅对当前节点有效,不会让子节点继承。如限制了IP防问A节点,但不妨碍该IP防问A的子节点 /A/B。
四、集群部署
zookeeper集群的目的是为了保证系统的性能承载更多的客户端连接设专门提供的机制。通过集群可以实现以下功能:
- 读写分离:提高承载,为更多的客户端提供连接,并保障性能。
- 主从自动切换:提高服务容错性,部分节点故障不会影响整个服务集群。
半数以上运行机制说明:
集群至少需要三台服务器,并且强烈建议使用奇数个服务器。因为zookeeper 通过判断大多数节点的存活来判断整个服务是否可用。比如3个节点,挂掉了2个表示整个集群挂掉,而用偶数4个,挂掉了2个也表示其并不是大部分存活,因此也会挂掉。
- 集群部署
配置语法:
server.节点ID=IP:数据同步端口:选举端口
- 节点ID:服务id手动指定1至125之间的数字,并写到对应服务节点的 {dataDir}/myid 文件中。
- IP地址:节点的远程IP地址,可以相同。但生产环境就不能这么做了,因为在同一台机器就无法达到容错的目的。所以这种称作为伪集群。
- 数据同步端口:主从同时数据复制端口,(做伪集群时端口号不能重复)。
- 选举端口:主从节点选举端口,(做伪集群时端口号不能重复)。
配置文件示例:
1 | |
集群配置流程:
1、分别创建3个data目录用于存储各节点数据
1 | |
2、编写myid文件
1 | |
3、编写配置文件
conf/zoo1.cfg
1 | |
conf/zoo2.cfg
1 | |
conf/zoo3.cfg
1 | |
4、分别启动
1 | |
5、分别查看状态
1 | |
检查集群复制情况:
1、分别连接指定节点
zkCli.sh 后加参数-server 表示连接指定IP与端口。
1 | |
2、任意节点中创建数据,查看其它节点已经同步成功。
注意: -server参数后同时连接多个服务节点,并用逗号隔开 127.0.0.1:2181,127.0.0.1:2182
集群角色说明
zookeeper 集群中总共有三种角色,分别是leader(主节点)follower(子节点) observer(次级子节点)
| 角色 | 描述 |
|---|---|
| leader | 主节点,又名领导者。用于写入数据,通过选举产生,如果宕机将会选举新的主节点。 |
| follower | 子节点,又名追随者。用于实现数据的读取。同时他也是主节点的备选节点,并用拥有投票权。 |
| observer | 次级子节点,又名观察者。用于读取数据,与fllower区别在于没有投票权,不能选为主节点。并且在计算集群可用状态时不会将observer计算入内。 |
observer配置:
只要在集群配置中加上observer后缀即可,示例如下:
1 | |
选举机制
通过 ./bin/zkServer.sh status <zoo配置文件> 命令可以查看到节点状态
1 | |
投票机制说明:
- 选举原则:比较每个节点的(zxid,myid),在当选节点的票数>总节点数/2(该原则可以避免zk集群的脑裂问题),zxid大者当选,若zxid相同再比较myid,myid大者当选;若当前已发生投票节点数未过半,则继续等待投票
Zookeeper选举机制——启动阶段的leader选举
zk集群至少要有3个节点,假如有5个节点1、2、3、4、5先后启动,它们启动时的zxid都是一样的(设为0):
->节点1进入looking选举状态,给自己投票,发出(0,1),此时当选节点票数=1<节点总数的一半=2.5,故节点1仍保持looking状态继续等待选举
->节点2进入looking选举状态,给自己投票,发出(0,2),myid为2最大,2当选,但此时当选节点票数=2<节点总数的一半=2.5,故节点2仍保持looking状态继续等待选举
->节点3进入looking选举状态,给自己投票,发出(0,3),myid为3最大,3当选,且此时当选节点票数=3>节点总数的一半=2.5,故节点3当选leader
->节点4进入looking选举状态,给自己投票,发出(0,4),但此时集群leader已选出,所以节点4仍成为follwer
->节点5进入looking选举状态,给自己投票,发出(0,5),但此时集群leader已选出,所以节点5仍成为follwer
->选举完成后,leader的状态由looking变为leading,follower的状态由looking变为following
总的来说,启动阶段的选举当选的必然为位于中间的节点

Zookeeper选举机制——运行阶段的选举
运行阶段每个节点的zxid都可能不同,但选举原则与启动阶段一样,都是先比较zxid,再比较myid,假如主节点3运行中挂掉了,其他所有从节点全部进入looking状态,节点1、2、4、5的zxid为121、122、124、125,且各从节点都推举自己为下一个leader,节点1发出(121,1),节点2发出(122,2),节点4发出(124,4),由于节点4的zxid比1、2的大,故4当选,且当选节点票数=3>总节点数/2=5/2=2.5,所以4当选新一代leader,节点5发出(125,5),但此时已经选举出leader,所以5成为follwer,最后leader变更状态为leading,follower变更为following