Zookeeper

Zookeeper

定义：是为分式应用程序提供的一个分布式开源协调服务框架，主要用于解决分布式集群中应用系统的一致性问题，提供了基于类似Unix系统的目录节点树方式的数据存储，可用于维护和监控存储的数据的状态的变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理，是Hadoop和Hbase的重要组件

数据模型：树形结构

zookeeper被设计用来实现协调服务（这类服务通常使用小数据文件），而不是用于大容量数据存储，因此一个znode能存储的数据被限制在1Mb以内
每个znode都可以通过其路径唯一标识

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wvHsMfiz-1626074988333)(C:\Users\16326\Desktop\dayHomework\QQ截图20210701213301.png)]

注意：不是二叉树！

zookeeper的作用：

1.负责提供阶段的监听注册作用

2.负责接收用户的心跳，进行通信，感知用户的状态

3.负责为用户提供注册，查找信息

4.负责负载均衡（如果现在新增一个服务器，要先完成在zookeeper中的注册，这时就知道可以有一个新的服务器可以用，分配任务时进行平均分配（负载均衡））

zookeeper集群的搭建：

进程布局：
qianfeng01：QuorumPeerMain
qianfeng02：QuorumPeerMain
qianfeng03：QuorumPeerMain

1.上传，解压，配置环境变量

2.编辑zoo_sample.cfg的副本zoo_cfg

内容如下：
tickTime=2000		---->定义的时间单元（单位ms），下面的两个值都是tickTime的倍数
initLimit=10		---->follower连接并同步leader的初始化连接时间
syncLimit=5			---->心跳机制的时间（正常情况下的请求和应答的时间）
dataDir=/usr/local/zookeeper/zkData		---->修改zookeeper的存储路径，只需要自己手动创建
clientPort=2181		---->客户端连接服务器的端口
#三个服务器节点
server.1=qianfeng01:2888:3888
server.2=qianfeng02:2888:3888
server.3=qianfeng03:2888:3888
解析：server.id=ip:port1:port2
id：服务器的id号，对应zkData/myid文件内的数字
ip：服务器的ip地址
port1：follower与leader交互的端口
port2：选举期间使用的port

注意：此文件不支持汉字注释

3.创建zkData，在里面创建myid，并添加id

4.远程拷贝至qianfeng02和qianfeng03

启动zookeeper：

1.三台机器上都启动zookeeper的服务（注意关闭防火墙）

zkServer.sh start		--->开启zkServer服务
zkServer.sh status		--->查看zkServer的状态

2.启动客户端的操作：

zkCli.sh -server ip:port	--->启动客户端，连接对应主机的服务进程
zkCli.sh 		--->启动客户端，连接本地服务进程

3.连接成功后可以使用下列指令：

ls------------查看某个目录包含的所有文件
[zk: localhost:2181(CONNECTED) 1] ls / 
[zookeeper]

ls2-----------查看某个目录包含的文件，他可以查到time，version等信息
[zk: localhost:2181(CONNECTED) 2] ls2 /
[zookeeper]
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x300000008
cversion = 1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1

create------------创建znode，并设置初始内容
[zk: localhost:2181(CONNECTED) 3] create /hello "hello world"
Created /hello
[zk: localhost:2181(CONNECTED) 4] ls /
[hello, zookeeper]

get---------------获取znode的内容
[zk: localhost:2181(CONNECTED) 7] get /hello
hello world
cZxid = 0x500000002
ctime = Thu Jul 01 22:16:38 CST 2021
mZxid = 0x500000002
mtime = Thu Jul 01 22:16:38 CST 2021
pZxid = 0x500000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 11
numChildren = 0

set---------------修改znode的内容
[zk: localhost:2181(CONNECTED) 8] set /hello "zaijiankaige"

delete-------------删除节点
[zk: localhost:2181(CONNECTED) 10] delete /hello

quit--------------退出
[zk: localhost:2181(CONNECTED) 12] quit
Quitting...

节点的状态：

ephemeral(短暂的)：客户端和服务器断开连接后，节点自己删除
persistent(持久的)：客户段和服务器断开连接后，节点默认不会自己删除

节点分类：

persistent：永久节点
persistent_sequential：永久有序节点
ephmeral：临时节点
ephmeral_sequential：临时顺序节点

Zookeeper的工作机制

选举机制：

选举制度中的四个概念：
leader：
	zookeeper集群工作的核心，事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性：集群内部各个服务器的调度者，对于create，setData，delete等有写操作的请求时，需要统一转发给leader处理，leader需要决定编号，执行操作，这个过程称为事务
	
follower：
	处理客户端非事务（读操作）请求，转发事务请求给leader
	参与集群的leader选举投票的2n-1台服务器可以做集群投票

observer：
	观察者角色，观察zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以独立处理，对于事务请求，则会转发给leader服务器进行处理，不会参与任何形式的的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力（访问量较大的集群才有此角色）

serverid（myid）：
	服务器的id，有三台服务器，编号为1，2，3，编号越大在选择算法中的权重就越大
zxid：
	zxid有64位，前32位标识epoch，后32位标识xid，xid是zk的事务id，每一次写操作都是一个事务，都会有一个xid，每一个写操作都会都leader发起一个提议，由所有的follower表决是否同意本次写操作
	
epoch：
	每个leader都会有一个不同的epoch值，表示一个时期，时代，新的leader产生，都会更新所有zkServer中的epoch
	
优先级：epoch > zxid > serverid

zookeeper中的状态说明：
looking：竞选状态
observing：观察者状态，同步leader状态，不参与选票
following：随从状态
leading：领导者状态

zookeeper中的选举机制（分成两种）：

全新集群选举：
	假设目前有三台机器进行选举，编号1，2，3，顺序启动：
	a，首先1号机器启动，投自己一票，此时集群有三台机器，只有1号一台机器正在正常工作，未达半数以上，所以1号服务器处于looking状态
	b，2号机器启动，此时，两台机器都会投自己一票，二者各一票，打平，此时二者互相交换信息，由于2号机器的myid比1号机器的myid，所以重新投一次票，1号会投2号，此时2号拿到票，拥有两票，刚好超过半数，所以当选为leader
	c，3号机器启动，此时由于集群已经有了leader，所以3号只能成为follower

非全新集群选举：
	对于运行正常的zookeeper集群，中途leader如果down掉，需要重新选举出leader时，就需要加入zxid，epoch，myid这三个条件综合考虑：
	a.epoch最大的服务器当选为leader
	b.epoch相同时，zxid大的服务器当选为leader
	c.zxid相同时，myid大的服务器当选为leader
	具体实施：
		Ⅰ，当zxid相同时，由于3号机器的myid大于1号机器的myid，所以3号机器当选为leader
		Ⅱ，当zxid不同时，如果1号zxid大于3号，那么1号当选为leader，反之3号当选为leader，这里1号zxid大于3号zxid的意思是：在2号宕机的时候，1号同步了2的事务，但是3号还未来得及同步，所以1号的zxid会大于3号

zookeepker的监听原理：

1.首先要有一个（main）主线程
2.在main线程总创建zookeeper客户端，这是会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）
3.通过connect线程将注册的监听事件发送给zookeeper
4.在zookeeper的注册监听器列表中将注册的监听事件添加到列表中
5.zookeeper监听到有数据或者路径的变化，就会将这个消息发送给listener线程
6.listener线程内部调用了process()方法

用途：
监听节点数据的变化
监听子节点增减的变化

zookeeper写流程：

1.client向zookeepker的server1上写数据，发送一个写请求
2.如果server1不是leader，那么server1会把请求进一步转发给leader
3.这个leader会将写请求广播给所有的server
4.各个server写成功后就会通知leader
5.当leader收到半数以上的server写成功的通知，就说明数据写成功了，写成功后，leader会告诉server1数据写成功了
6.server1会进一步通知client数据写成功了，这时就认为整个写操作成功

HA（high available）：

定义：

high avaliable：指的是集群7*24小时，不间断地对外提供服务

使用原因：

因为在hadoop1.0的hdfs集群中，只有一个namenode，只有一个namenode对外提供服务，当这个namenode因为意外宕机，或者是由于升级硬件或者软件，导致namenode停机，此时整个集群中将处于不可用状态

高可用的备份方式：

3.1主从模式（冷备）：

准备两台服务器，准备相同的程序，一台服务器对外提供服务，称为主节点（active），另外一台服务器平时不对外提供服务，主要负责和active节点之间进行数据的同步，称为备份节点（standby节点），当主节点出现故障，standby节点可以提升为active节点，对外提供服务

zookeeper实现的集群高可用，就采用的是这种模式

3.2双主互备（热备）：

准备两台服务器，准备相同的程序，同时对外提供服务（此时，这两台服务器彼此成为对方的备份），这样，当一台节点宕机时，另外一台节点还可以继续提供服务

3.3集群多备：

基本上等同于双主互备，区别就在于同时对外提供服务地节点数量更多，备份数量更多

两个namenode的缺点：

由于standbynamenode代替了secondarynamenode节点，在同步日志的时候，如果出现网络动荡，很容易丢失数据，造成数据的不一致性，解决办法：journalNode集群

手动高可用：

hadoop2.0版本之后，Clouera提出了QJM（QuromJournal Manager），这是一个基于Paxos算法实现的HA方案：
1.基本的原理：
	使用2N+1台JN存储Editlog，每次写入数据的时候，有半数以上的JN返回成功的信息，就表示本次的操作已经同步到了JN
2.在HA中，SecondaryNameNode这个角色已经不存在了，保证Standby节点的元数据信息与active节点的元数据信息一致，需要通过若干个JN
3.当有任何的操作发生在active结点的时候，JN会记录这些操作到半数以上的节点，standby节点检测到JN的log日志文件发生了变化，会读取   JN中的数据到自己的内存中，维护最新的目录树结构与元数据信息
4.当发生故障的时候，active节点挂掉，此时standby节点在成为active节点之前，会将读取到的Editlog文件在自己的内存中进行推演，得   到最新的目录树结构，此时再去升为active节点，可以无缝继续对外提供服务

自动高可用：

qianfeng01	qianfeng02	qianfeng03
NameNode	NameNode
DataNode	DataNode	DataNode
ResourceManager
NodeManager	NodeMnager	NodeManger
QuorumPeerMain	QuorumPeerMain	QuorumPeerMain
JournalNode	JournalNode	JournalNode
ZKFC	ZKFC

journalNode集群的功能介绍：

1.每个journalnode节点都存储编辑日志

为了使备用节点保持其状态与活跃节点同步，两个节点都与一组称为“journalNode”（jn）的单独进程进行通信，当活动节点执行任何命名空间的修改时，它会持久地将修改记录记录到jn中，standby节点会以查看编辑日志的方式一直监视jn。当备用节点看到编辑内容修改之后，会将其应用于自己的命名空间，发生故障转移时，备用节点将确保在自身升级为活动状态之前，已从jounalnodes读取所有编辑内容，这样可以确保在在发生故障转移之前，命名空间状态已完全同步

2.防止脑裂发生

	对于HA集群的正常操作至关重要，一次只能有一个namenode处于active状态，否则，命名空间状态将在两者之间迅速分散，从而有数据丢失或者其他不正确的结果的风险
	
脑裂：
	就是active节点处于网络震荡状态，假死状态，standby就转为active，等网络震荡之后，就有两个active了，这时就称为脑裂
	
解决办法：
	为了确保该属性并防止所谓的脑裂情况，journalnode将一次仅允许单个namenode成为作者，在故障转移期间，变为活跃的namenode将仅承担写入journalnode的角色，这将有效地防止另一个namenode继续处于活动状态，从而使新的avtive可以安全地进行故障转移

3.journalnode集群正常工作的条件：

至少3个journalnode节点

4.datanode同时向两个namenode发送心跳反馈

为了提供快速的故障转移，备用节点还必须具有集群中块位置的最新信息。为了实现这一点，datanode被配置了两个namenode的位置，并向两者发送快位置信息和心跳信号

journalnode的缺点：

在这种模式下，即使活动节点发生故障，系统也不会自动触发从活动namenode到备用namenode的故障转移，必需要有人为的操作才行，要是有一个能监视active节点的服务功能就好了，此时zookeeper的作用就发挥出来了，来帮助我们进行自动容灾

HA的自动容灾处理的原理：

如果想进行HA的自动故障转移，那么需要为HDFS部署两个新组件：zookeeper quorum和ZKFailoverController（缩写ZKFC）

zookeeper quorum：是apache zookeeper的一项高可用性服务，用于维护少量的协调数据，将数据中的更改通知客户端并监听客户端的故障，HDFS自动故障转移的实现依赖于zookeeper

故障检测：
	集群中的每个namenode计算机都在zookeeper中维护一个持久性会话，如果计算机崩溃，那么zookeeper会话将终止，通知另外一个namenode应触发故障转移

active的namenode选举（ha的第一次选举）
	zookeeper提供了一种简单的机制来专门选举一个节点作为活动的节点，如果当前的active的namenode奔溃，则另外一个节点可能会在zookeeper种采取特殊的排他锁，指示它应成为下一个活动的namenode

zkfc介绍：

zkfavilorcontroller是一个新组件，它是一个zookeeper客户端，他监视和管理namenode的状态，运行namenode的每台机器都有一个zkfc，该zkfc负责下面内容：

运行状况监视：
	zkfc使用运行状况检查命令定期ping其本地的namenode，只要namenode以健康状态及时响应，那么zkfc就认为该结点是健康的，如果节点崩溃，冻结或者以其他方式进入不正常状态，则运行状况监视器将其标记为不正常

zookeeper会话管理：
	当本地namenode运行状况良好时，zkfs会在zookeeper中保持打开的会话，如果本地的namenode处于活动状态，则他还将持有一个特殊的“锁定”znode，该锁使用zookeeke对“临时”节点的支持，如果会话到期，那么锁定节点将被自动删除

基于zookeeper的选举：

自动容灾处理：

zkfc（是一个进程，和nn在同一物理节点上）有两只手，分别拽着nn和zookeeper（监控namenode的健康状态，并向zookeeper注册namenode）
集群启动时，两个zkfc会判断自己的namenode是否健康，如果健康，2个zkfc会向zookeeper集群抢着创建一个临时节点，结果就只有一个会最终创建成功，从而决定active和standby位置，如果zkfc1抢到了节点，zkfc2没有抢到，zkfc2也会监控watch这个节点
如果zkfc1的activenamenode异常退出，zkfc1会最先知道，就访问zookeeper，zookeeper就会把曾经创建的节点删掉，删除节点是一个事件，谁监控这个节点，就会调用callback回调，zkfc2就会把自己的地位上升为active，但在此之前，要先确认zkfc1的节点是否真的挂掉，此时就要引入第三只手的概念：
zkfc2通过ssh远程连接zkfc1的namenode尝试对方降级，判断对方是否真的挂掉了，确认真的不健康，zkfc2管辖的namenode才会上升地位到active，所以在zkfc2的步骤是：
1.创建新的节点
2.第三只手将对方降级
3.把自己升级

那如果namenode没有出现问题，反而是zkfc挂掉了呢，zookeeper有一个客户端session机制，集群启动之后，2个zkfc除了监控自己的namenode还要和zookeeper建立一个tcp长协议，并各自获取自己的session只要一方的session失效，zookeeper就会删除该方创建的节点，同时另一方创建节点，上升地位

己的地位上升为active，但在此之前，要先确认zkfc1的节点是否真的挂掉，此时就要引入第三只手的概念：
zkfc2通过ssh远程连接zkfc1的namenode尝试对方降级，判断对方是否真的挂掉了，确认真的不健康，zkfc2管辖的namenode才会上升地位到active，所以在zkfc2的步骤是：
1.创建新的节点
2.第三只手将对方降级
3.把自己升级

那如果namenode没有出现问题，反而是zkfc挂掉了呢，zookeeper有一个客户端session机制，集群启动之后，2个zkfc除了监控自己的namenode还要和zookeeper建立一个tcp长协议，并各自获取自己的session只要一方的session失效，zookeeper就会删除该方创建的节点，同时另一方创建节点，上升地位