Zookeeper学习笔记

• 一、概述
• • 1.1、Zookeeper
  • 1.2、Zookeeper工作机制
  • 1.3、Zookeeper特点
  • 1.4、数据结构
  • 1.6、应用场景
  • • 1.6.1、统一命名服务
    • 1.6.2、统一配置管理
    • 1.6.3、统一集群管理
    • 1.6.4、服务器动态上下线
    • 1.6.5、软负载均衡
• 二、下载安装
• • 2.1、集群规划
  • 2.1、集群规部署
• 三、zk选举
• • 3.1、第一次启动选举
  • 3.2、非第一次启动的选举

一、概述

1.1、Zookeeper

Zookeeper是一个开源的分布式的，为分布式框架提供协调服务的Apache项目。

1.2、Zookeeper工作机制

Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

1.3、Zookeeper特点

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

1.4、数据结构

ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode.,默认能够存储1MB 的数据，每个ZNode都可以通过其路径唯一标识。

1.6、应用场景

1.6.1、统一命名服务

IP不容易记住，而域名容易记住。

1.6.2、统一配置管理

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

1.6.3、统一集群管理

1. 分布式环境中，实时掌握每个节点的状态是必要的。
   (1)可根据节点实时状态做出一些调整。
2. ZooKeeper可以实现实时监控节点状态变化
   (1）可将节点信息写入ZooKeeper上的一个ZNode。(2）监听这个ZNode可获取它的实时状态变化。

1.6.4、服务器动态上下线

客户端能实时洞察到服务
器上下线的变化

1.6.5、软负载均衡

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

二、下载安装

2.1、集群规划

2.1、集群规部署

官网
稳定版本3.5.7

首先需要安装JDK 安装JDK教程

将下载的zk上传到服务器并解压

tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz

先在解压后的文件里创建一个datas文件夹并赋权777

在建立的datas里创建一个文本myid 并输入相关的id保存

然后将conf/zoo_sample.cfg 改名成zoo.cfg

# 通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
tickTime=2000
# LF初始通信时限
# Leader和Follower初始连接时能容忍的最多心跳数
initLimit=10
# LF同步通信时限
# Leader和Follower之间通信时间如果超过syncLimit * tickTime
# Leader认为Follwer死掉，从服务器列表中删除Follwer。
syncLimit=5
# 保存Zookeeper中的数据
dataDir=/usr/soft/zookeeper/datas
# 客户端连接端口，通常不做修改
clientPort=2181# 集群配置信息# 配置格式：server.A=B:C:D# server：固定写法# A:是一个数字，表示这个服务器的编号# B:是这个服务器的ip地址或主机名# C:Zookeeper服务器之间的数据同步等通信端口# D:Leader选举的端口
server.1=192.168.3.34:2888:3888
server.2=192.168.3.35:2888:3888
server.3=192.168.3.36:2888:3888

关闭防火墙

systemctl stop firewalld.service
#关闭防火墙开机自启
systemctl disable firewalld.service

Zookeeper启停

# 进入Zookeeper的bin文件夹启动服务器
# 启动zookeeper 每一个都要输入
./zkServer.sh start# 查看状态
./zkServer.sh status# 停止
./zkServer.sh stop# 进入zookeeper的bin文件夹启动客户端
./zkCli.sh
ls /

三、zk选举

3.1、第一次启动选举

1. 服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上(3票)，选举无法完成，服务器1状态保持为LOOKING;
2. 服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的myid 比自己目前投票推举的(服务器1)大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
3. 服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING;
4. 服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果:服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING;
5. 服务器5启动，同4一样

SID：服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。

ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。

Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加

3.2、非第一次启动的选举

1. 当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举:

• 服务器初始化启动。
• 服务器运行期间无法和Leader保持连接。

2. 而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态:

• 集群中本来就已经存在一个Leader。
  对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前集群的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
• 集群中确实不存在Leader。
  假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举。
• 选举Leader规则:①EPOCH大的直接胜出②EPOCH相同，事务id大的胜出③事务id相同,服务器id大的胜出