大数据修炼之Zookeeper

本文主要是介绍大数据修炼之Zookeeper，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

概述
原理
客户端命令
节点
集群
分布式锁实现

https://zookeeper.apache.org/

概述

分布式系统资源协调服务中间件。

从设计模式角度看，zk是一个基于观察者设计模式的分布式服务管理框架，接受观察者注册，负责储存管理关心的数据，接受观察者注册。

zk=文件系统+通知机制

特点：

一致性，最终一致性
原子性
单一视图，无论是连到哪个节点，数据是一致的
可靠性：每次操作都会保存到数据库，每个server保存一份相同的数据副本
更新请求顺序进行，来此同一个client的更新按其发送顺序依次执行。
实时性，在一定时间范围内，client能读到最新的数据

数据模型的结构整体可以看作是一个树，每个节点称作ZNode，每个znode默认存储1MB数据，每个ZNode都可以存储数据。

应用场景：

数据发布订阅，集中式配置中心（推拉）
软负载均衡 https://blog.csdn.net/autfish/article/details/51576695
集群管理：多少机器在工作，每台机器的运行状态，集中上线下操作，分布式任务状态汇报。

原理

分布式一致性协议介绍（Paxos、Raft）
在这里插入图片描述

客户端命令

bin/zkCli.sh -server 127.0.0.1:2181

ZooKeeper -server host:port cmd args
addauth scheme auth
close
config [-c] [-w] [-s]
connect host:port
create [-s] [-e] [-c] [-t ttl] path [data] [acl]
delete [-v version] path
deleteall path
delquota [-n|-b] path
get [-s] [-w] path
getAcl [-s] path
getAllChildrenNumber path
getEphemerals path
history
listquota path
ls [-s] [-w] [-R] path
ls2 path [watch]
printwatches on|off
quit
reconfig [-s] [-v version] [[-file path] | [-members serverID=host:port1:port2;port3[,...]*]] | [-add serverId=host:port1:port2;port3[,...]]* [-remove serverId[,...]*]
redo cmdno
removewatches path [-c|-d|-a] [-l]
rmr path
set [-s] [-v version] path data
setAcl [-s] [-v version] [-R] path acl
setquota -n|-b val path
stat [-w] path
sync path

节点

节点类型
1、Znode有两种类型：
短暂（ephemeral）（断开连接自己删除）
持久（persistent）（断开连接不删除）
2、Znode有四种形式的目录节点（默认是persistent ）
PERSISTENT
PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ） create -s /data data
EPHEMERAL create -e /data data
EPHEMERAL_SEQUENTIAL create -s -e /data data

在这里插入图片描述
常用四字命令：
telnet或者nc
runk 服务是否处于正常状态
conf 打印相关配置信息
cons 列出所有连接到这台服务器的客户端连接/会话信息
crst 重置所有连接和绘画的统计信息
dump 列出比较重要的会话和临时节点，只能在leader有用
envi 打印出服务环境的详细信息

集群

zk有一个leader多个follower
leader 负责进行投票的发起和决议，更新系统状态
follower接受客户端并向客户端返回结果，在leader选举中进行投票
集群中只要半数以上的节点存活，就能正常服务（适合奇数台机器）
zk的集群可以主从复制，但是没用读写分离
follower掉线后，重新上线可以同步数据

参考paxos协议

zookeeper的选举机制（全新集群paxos）
以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么.

服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
服务器5启动,同4一样,当小弟.

非全新集群的选举机制(数据恢复)
那么，初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。
需要加入数据id、leader id和逻辑时钟。
数据id：数据新的id就大，数据每次更新都会更新id。
Leader id：就是我们配置的myid中的值，每个机器一个。
逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新.
选举的标准就变成：
1、逻辑时钟小的选举结果被忽略，重新投票
2、统一逻辑时钟后，数据id大的胜出
3、数据id相同的情况下，leader id大的胜出
根据这个规则选出leader。