Zookeeper3.5.7基础学习
Zookeeper3.5.7基础学习
一、Zookeeper入门
1、概述
Zookeeper 是一个开源的分布式的,为分布式框架提供协调服务的 Apache 项目
Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应**。Zookeeper=文件系统+通知机制**
2、特点
- Zookeeper:一个领导者(Leader),多个跟随者(Follower)组成的集群
- 集群中只要有半数以上节点存活,Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器
- 全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个Server,数据都是一致的
- 更新请求顺序执行,来自同一个Client的更新请求按其发送顺序依次执行
- 数据更新原子性,一次数据更新要么成功,要么失败
- 实时性,在一定时间范围内,Client能读到最新数据
3、数据结构
ZooKeeper 数据模型的结构与 Unix 文件系统很类似,整体上可以看作是一棵树,每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据,每个 ZNode 都可以通过其路径唯一标识
4、应用场景
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等
- 统一命名服务
在分布式环境下,经常需要对应用/服务进行统一命名,便于识别。例如:IP不容易记住,而域名容易记住
- 统一配置管理
分布式环境下,配置文件同步非常常见。一般要求一个集群中,所有节点的配置信息是一致的,比如 Kafka 集群。对配置文件修改后,希望能够快速同步到各个节点上。配置管理可交由ZooKeeper实现。可将配置信息写入ZooKeeper上的一个Znode;各个客户端服务器监听这个Znode;一旦Znode中的数据被修改,ZooKeeper将通知各个客户端服务器。
- 统一集群管理
分布式环境中,实时掌握每个节点的状态是必要的。可根据节点实时状态做出一些调整。ZooKeeper可以实现实时监控节点状态变化可将节点信息写入ZooKeeper上的一个ZNode。监听这个ZNode可获取它的实时状态变化。
- 服务器动态上下线
客户端能实时洞察到服务器上下线的变化
- 软负载均衡
在Zookeeper中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请求
二、Zookeeper 安装部署
1、本地模式安装
1.1 基础操作
1 | # 首先自行安装jdk,这里我就继续在之前的hadoop集群上继续操作了 |
1.2 配置参数解读
vim zoo.cfg
1 | # 通信心跳时间,Zookeeper服务器与客户端心跳时间,单位毫秒 |
2、集群部署
2.1 集群安装
1 | # 在 hadoop102、hadoop103 和 hadoop104 三个节点上都部署 Zookeeper(这是之前hadoop集群用的) |
2.2 选举机制(面试重点)
2.3 ZK 集群启动停止脚本
在 hadoop102 的/home/atguigu/bin 目录下创建脚本: vim zk.sh
1 |
|
1 | # 增加脚本执行权限 |
三、ZK客户端相关操作
1、客户端命令行操作
1.1 命令行语法
1 | # 启动客户端 |
命令基本语法 | 功能描述 |
---|---|
help | 显示所有操作命令 |
ls path | 使用 ls 命令来查看当前 znode 的子节点 [可监听] -w 监听子节点变化 -s 附加次级信息 |
create | 普通创建 -s 含有序列 -e 临时(重启或者超时消失) |
get path | 获得节点的值 [可监听] -w 监听节点内容变化 -s 附加次级信息 |
set | 设置节点的具体值 |
stat | 查看节点状态 |
delete | 删除节点 |
deleteall | 递归删除节点 |
1.2 znode 节点数据信息
1 | # 查看当前znode中所包含的内容 |
- czxid:创建节点的事务 zxid。每次修改ZooKeeper 状态都会产生一个ZooKeeper 事务 ID。事务 ID 是ZooKeeper 中所有修改总的次序。每次修改都有唯一的 zxid,如果 zxid1 小于 zxid2,那么zxid1 在 zxid2 之前发生。
- ctime:znode 被创建的毫秒数(从 1970 年开始)
- mzxid:znode 最后更新的事务zxid
- mtime:znode 最后修改的毫秒数(从 1970 年开始)
- pZxid:znode 最后更新的子节点zxid
- cversion:znode 子节点变化号,znode 子节点修改次数
- dataversion:znode 数据变化号
- aclVersion:znode 访问控制列表的变化号
- ephemeralOwner:如果是临时节点,这个是 znode 拥有者的 session id。如果不是临时节点则是 0
- dataLength:znode 的数据长度
- numChildren:znode 子节点数量
1.3 节点类型(持久/短暂/有序号/无序号)
1 | # 分别创建2个普通节点(永久节点 + 不带序号) |
1.4 节点删除与查看
1 | # 删除节点 |
2、监听器原理
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、节点删除、子目录节点增加删除)时,ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序
1 | # 节点的值变化监听 |
3、客户端 API 操作
前提:保证 hadoop102、hadoop103、hadoop104 服务器上 Zookeeper 集群服务端启动
创建zookeeper工程,引入对应依赖
1 | <dependency> |
需要在项目的 src/main/resources 目录下,新建一个文件,命名为"log4j.properties",填入数据
1 | log4j.rootLogger=INFO, stdout |
创建包名com.atguigu.zk,创建类名称zkClient
1 | public class zkClient { |
4、客户端向服务端写数据流程
写流程之写入请求直接发送给Leader节点(写完半数即可返回成功)
写流程之写入请求发送给follower节点
四、ZK生产环境案例
1、服务器动态上下线监听案例
1.1 需求分析
某分布式系统中,主节点可以有多台,可以动态上下线,任意一台客户端都能实时感知到主节点服务器的上下线。
1.2 具体实现
首先在集群上创建/serves节点 create /servers "servers"
在 Idea 中创建包名:com.atguigu.zkcase1,创建服务端DistributeServer
1 | public class DistributeServer { |
创建客户端DistributeClient
1 | public class DistributeClient { |
1.3 测试与分析
1 | # 首先启动客户端 |
2、ZooKeeper 分布式锁案例
2.1 概述
分布式锁的概念可以参考:几种分布式锁详解
2.2 原生 Zookeeper 实现分布式锁案例
1 | public class DistributedLock { |
测试代码
1 | public class DistributedLockTest { |
2.3 Curator 框架实现分布式锁案例
原生的 Java API 开发存在的问题会话,连接是异步的,需要自己去处理。比如使用 CountDownLatch;Watch 需要重复注册,不然就不能生效;开发的复杂性还是比较高的;不支持多节点删除和创建。需要自己去递归
Curator 是一个专门解决分布式锁的框架,解决了原生 JavaAPI 开发分布式遇到的问题,首先添加依赖
1 | <dependency> |
代码实现
1 | public class CuratorLockTest { |
五、总结
1、UI界面安装
2、企业面试真题(面试重点)
2.1 选举机制
半数机制,超过半数的投票通过,即通过
第一次启动选举规则:
- 投票过半数时,服务器 id 大的胜出
第二次启动选举规则:
- EPOCH 大的直接胜出
- EPOCH 相同,事务 id 大的胜出
- 事务 id 相同,服务器 id 大的胜出
2.2 生产集群安装多少 zk 合适?
安装奇数台。服务器台数多:好处,提高可靠性;坏处:提高通信延时。生产经验:
- 10 台服务器:3 台 zk;
- 20 台服务器:5 台 zk;
- 100 台服务器:11 台 zk;
- 200 台服务器:11 台 zk
2.3 常用命令
ls、get、create、delete