Zookeeper的架构和客户端操作(一)

发布于 2021-07-24  2.08k 次阅读

Zookeeper是一个开源的分布式的，为分布式框架(比如Haddop)和微服务框架(Dubbo)提供协调服务的Apache项目

一，Zookeeper的工作机制和特点

Zookeeper从设计模式角度是一个基于观察者设计模式的分布式服务管理框架，它负责存储和管理服务都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应
本质上Zookeeper是一个文件系统(K-V形式)和通知机制的结构，其他框架的核心信息会保存在Zookeeper的K-V中，Zookeeper对信息进行监听，当数据发生变动，Zookeeper会进行通知，其他框架服务也可以对Zookeeper中的数据进行获取和调用

特点：

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

二，Zookeeper的数据结构和应用场景

 一，ZK数据结构

   Zookeeper数据模型的结构与Linux文件系统很相似，整体可以看作是由一个个节点组成的树，每一个节点称作ZNode，每一个ZNode默认能够存储1MB的数据，每一个ZNode节点都有唯一的标识
 
Zookeeper数据模型是节点组成的树，实际存储数据结构是K-V型的，每个节点存储的数据量很小
 
注：Zookeeper数据结构不像Redis支持5种基本类型，它只有一种K-V型
 
数据模型：Node树
数据结构：K-V

二，ZK的应用场景

Zookeeper提供的服务包括：
  1. 统一命名服务
  2. 统一配置管理
  3. 统一集群管理
  4. 服务器节点动态上下线
  5. 软负载均衡

一，统一命名服务

在分布式环境下，经常需要对应用服务进行统一命名，便于识别，例如：IP不容易记住，而域名容易记住

二，统一配置管理

1，分布式环境下，经常需要配置文件同步操作
 
①，一般要求集群中所有的节点配置信息是一致的，比如：Haddop集群，Kakaf集群
 
②，对配置文件修改后，希望能够快速同步到各个节点上
 
2，配置管理交由zookeeper实现
①，可以将配置信息写入Zookeeper上的Znode节点中
 
②，各个客户端服务器监听这个Znode，
 
③，一旦Znode中的数据发生修改，Zookeeper将通知各个客户端服务器，他们再进行同步

三，统一集群管理

1，分布式环境中，实时掌握每一个节点的状态是很重要的
 
① 根据节点的实时状态对集群做出调整
 
2，Zookeeper可以实现实时监控节点的状态变化
 
① 将节点信息写入Zookeeper上的ZNode
 
② 监听这个ZNode可获取它的实时状态变化

四，软负载均衡

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
 
注：使用zookeeper做负载均衡可以使用其他负载策略，不局限于最小活跃数(这是使用Zookeeper最适合做的负载均衡策略)

三，Zookeeper的选举机制

Zookeeper的选举机制分两种情况：

  • 第一次启动时选举
  • 非第一次启动时选举

一， 第一次启动时Zookeeper选举机制

设有五台服务器
 
1）服务器1启动时，发起一次选举，服务器1投自己一票，此时服务器1票数一票，不够半数以上(3票)，选举无法完成，服务器1保存LOOKING状态
 
注：LOOKING是一个特殊的
 
2）服务器2启动，再发起一次选举，服务器1和2分别投自己一票并交换选票信息，此时服务器1发现服务器2的myid比自己目前投票推举的(服务器1)大，更改选票推荐服务器2，此时服务器1票数为0，服务器2票数为2，都没有到达半数以上，选举无法完成，服务器1，服务器2都保存LOOKING状态
 
注：当服务器1投票后发现自己成不了Leader，就会把选票给下一个选举服务器，因而需要比较myid，当myid比自己大，直接把选票全部给下一个服务器
3）服务器3启动，发起一次选举，此时服务器1和2都会更该选票为服务器3，此时投票结果：服务器1为0，服务器2为0，服务器3为3超过半数，服务器3当选Leader，服务器1和服务器2为Follower
 
4）服务器4启动，发起一次选举，此时服务器1，2，3都已经不是LOOKING状态，不会交换选票信息，因此服务器4只有1票，为Follower
 
5）服务器5启动和服务器一样
Zookeeper的三大ID：
  1. SID：服务器ID，用来唯一标识一台Zookeeper集群中的机器，每一台机器不能重复(myid文件就是标明SID)
  2. ZXID：事务ID，用来标识一次服务器状态的变更(对zookeeper的读写)，在某一时刻，集群中的每一台机器的ZXID值不一定完全一致这和服务端和客户端的处理逻辑有关
  3. Epoch：每一个Leader任期的代号，没有Leader时同一次投票过程中的逻辑时钟值是相同的，每投完一票这个值就会增加

二，非第一次启动时Zookeeper选举机制

集群中的一台机器出现以下情况就会进行Leader选举：
  1. 服务器初始化：就是启动时选举
  2. 服务器运行期间Leader宕机无法连接
 
当一台机器进入Leader选举流程时，当前集群也可能处于两种状态：
  • 集群本来已经存在一个Leader
对于已经存在Leader的情况，机器尝试去选举Leader时，会被告知当前集群的Leader信息(IP地址，端口信息)，机器不再进行选举，仅仅需要和Leader机器建立连接，进行状态同步即可
  • 集群中不存在Leader
假设Zookeeper由5台服务器组成，SID分别为1,2,3,4,5，ZXID分别为8,8,8,7,7，并且此时SID为3的服务器是Leader，某一时刻3和5机器发生故障宕机，Leader宕机，剩下的3台机器1，2，4进行选举
 
此时三台机器的信息：(EPOCH，ZXID，SID)
  • 机器1：(1，8，1)
  • 机器2:（1，8，2）
  • 机器4：(1，7，4)
 
此时选举的规则：需要判断三个值(优先级依次递减)
  1. EPOCH大的直接胜出
  2. EPOCH相同，事务ZXID大的胜出
  3. ZXID相同，服务器SID大的胜出
 
最终机器2成为新大Leader

四，Zookeeper的安装

 
一般用3.5.7稳定版本

一，Zookeeper本地安装

一，zookeeper底层是java编写的，需要安装JDK环境

① 下载JDK
 
注：下载类型为tar.gz的linux tar压缩包类型

② 上传文件到linux中
文件上传主要有两种方式：
1，通过FTP文件传输客户端(需要单独下载XFTP工具)
 
2，通过linux的rz文件传输命令(一些轻量级安装的iso镜像没有自带，需要单独安装)
安装RZ：yum install lrasz
传输命令：
  • rz：从本地上传到服务器
  • sz filename：从服务器下载到本地
③ 解压文件
命令：tar -zxvf 压缩包名

④ 配置环境变量
在 /etc/profile 文件下配置环境变量
配置内容：要修改为对应的JDK路径
export JAVA_HOME=/home/JDK
export PATH=$PATH:$JAVA_HOME/bin
⑤ 重启配置
命令：source  /etc/profile
⑥ 检查java是否安装成功
命令：java -version

二，本地安装Zookeeper

① 下载Zookeeper的Linux压缩包(tar.gz)
 
② 上传到Linux系统