Zookeeper_zk半数存活

Zookeeper

1.1 概述

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

Zookeeper工作机制

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

1.2 特点

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

1.3 数据结构

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

1.4 应用场景

提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。

统一命名服务

在分布式环境下，经常需要对应用/服务进行统一命名，便于标识。

例如：ip难记，域名容易记住。

统一配置管理

1）分布式环境下，配置文件同步非常常见。

​ （1）一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群。

​ （2）对配置文件修改后，希望能够快速同步到各个节点上。

2)配置管理Zookeeper实现。

​ （1）可以将配置信息写入Zookeeper上的一个Znode。

​ （2）各个客户端服务器监听这个Znode。

​ （3）一旦Znode中的数据被修改，Zookeeper将通知各个客户端服务器。

同一集群管理

1）分布式环境中，实时掌握每个节点的状态是必要的。

​ （1）可根据节点实时状态做出一些调整

2）Zookeeper可以实现监控节点状态变化

​ （1）可将节点信息写入Zookeeper上的一个Znode。

​ （2）监听这个Znode可以获取它的实时状态变化。

服务器动态上下线

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

软负载均衡

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

1.5 下载地址

1．官网首页：

https://zookeeper.apache.org/

Zookeeper安装

2.1 本地模式安装部署

1．安装前准备

（1）安装Jdk

（2）拷贝Zookeeper安装包到Linux系统下

（3）解压到指定目录

[atguigu@hadoop102 software]$ tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/
1

2．配置修改

（1）将/opt/module/zookeeper-3.4.10/conf这个路径下的zoo_sample.cfg修改为zoo.cfg；

[atguigu@hadoop102 conf]$ mv zoo_sample.cfg zoo.cfg
1

（2）打开zoo.cfg文件，修改dataDir路径：

[atguigu@hadoop102 zookeeper-3.4.10]$ vim zoo.cfg
1

修改如下内容：

dataDir=/opt/module/zookeeper-3.4.10/zkData
1

（3）在/opt/module/zookeeper-3.4.10/这个目录上创建zkData文件夹

[atguigu@hadoop102 zookeeper-3.4.10]$ mkdir zkData
1

3．操作Zookeeper

（1）启动Zookeeper

[atguigu@hadoop102 zookeeper-3.4.10]$ bin/zkServer.sh start
1

（2）查看进程是否启动

[atguigu@hadoop102 zookeeper-3.4.10]$ jps

4020 Jps

4001 QuorumPeerMain

1
2
3
4
5
6

（3）查看状态：

[atguigu@hadoop102 zookeeper-3.4.10]$ bin/zkServer.sh status

ZooKeeper JMX enabled by default

Using config: /opt/module/zookeeper-3.4.10/bin/../conf/zoo.cfg

Mode: standalone
1
2
3
4
5
6
7

（4）启动客户端：

[atguigu@hadoop102 zookeeper-3.4.10]$ bin/zkCli.sh
1

（5）退出客户端：

[zk: localhost:2181(CONNECTED) 0] quit
1

（6）停止Zookeeper

[atguigu@hadoop102 zookeeper-3.4.10]$ bin/zkServer.sh stop
1

2.2 配置参数解读

Zookeeper中的配置文件zoo.cfg中参数含义解读如下：

1．tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒

Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。

它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)

2．initLimit =10：LF初始通信时限

集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。

3．syncLimit =5：LF同步通信时限

集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。

4．dataDir：数据文件目录+数据持久化路径

主要用于保存Zookeeper中的数据。

5．clientPort =2181：客户端连接端口

监听客户端连接的端口。

Zookeeper内部原理

3.1 选举机制（面试重点）

1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

3）以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图所示。

（1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。

（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。

（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。

（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。

（5）服务器5启动，同4一样当小弟。