zookeeper搭建使用

最新推荐文章于 2024-08-13 18:17:31 发布

为何而努力

最新推荐文章于 2024-08-13 18:17:31 发布

阅读量139

点赞数

分类专栏： zookeeper 文章标签： zookeeper java linux 分布式

本文链接：https://blog.csdn.net/hjs19981227/article/details/107643633

版权

zookeeper 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

zookeeper安装和配置

zookeeper简述

解决单点故障
毫秒级处理
解决分布协调的问题

在这里插入图片描述
Zookeeper 是 Google 的 Chubby一个开源的实现，是 Hadoop 的分布式协调服务 service
包含一个简单的原语集，分布式应用程序可以基于它实现：
开源领域首屈一指

角色模型
集群状态（可用/不可用）
主从分工
攘其外：
统一视图
会话session
数据模型Znode
目录结构
节点类型
事件监听Watcher
原理：
原子消息广播协议ZAB
paxos
journalnode
sentinel
zookeeper  ZAB
zxid ,myid：
ZXID:epoch+ID
广播模式原理
恢复模式原理：无主模型：zab： zxid ,myid
应用场景
统一命名
配置管理
集群管理

角色模型
集群状态
选举模式安其内
广播模式壤其外
Server状态
LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
LLOWING：leader已经选举出来，当前Server与之同步
主从分工
领导者（leader）
负责进行投票的发起和决议，更新系统状态
学习者（learner）
包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票
Observer
可以接受客户端连接，将写请求转发给 leader，但observer不参加投票过程，只同步leader 的状态，observer的目的是为了扩展系统，提高读取速度
客户端（client）
请求发起方

大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等）
目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制
协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器
ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用
	Keepalived监控节点不好管理
	Keepalive 采用优先级监控
	没有协同工作
	功能单一

	Keepalive可扩展性差Hadoop,使用Zookeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等.
	HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等.

在conf目录下创建一个配置文件zoo.cfg，
tickTime=2000
dataDir=/Users/zdandljb/zookeeper/data dataLogDir=/Users/zdandljb/zookeeper/dataLog clientPort=2181
initLimit=5 syncLimit=2
server.1=server1:2888:3888
server.2=server2:2888:3888
server.3=server3:2888:3888
创建myid文件

tickTime：发送心跳的间隔时间，单位：毫秒
dataDir：zookeeper保存数据的目录。
clientPort：客户端连接 Zookeeper 服务器的端口，Zookeeper  会监听这个端口，接受客户端的访问请求。
initLimit： 这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连  接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的  Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的  时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表  明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最

长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4 秒
server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号

在这里插入图片描述
提供集群模式的服务
原子性
准确的反馈成功或失败
一致性
每个server都有统一的数据视图
可用性
节点故障不影响使用
网络分区/脑裂：过半通过
3台机器挂一台 2>3/2
4台机器挂2台 2！>4/2
顺序性：队列FIFO
主从模型
一写多读
数据模型Znode
目录结构节点间具有父子关系
层次的，目录型结构，便于管理逻辑关系
节点znode而非文件file
znode信息
包含最大1MB的数据信息
记录了Zxid等元数据信息
节点类型

主从模式

Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
Znode支持序列SEQUENTIAL：leader
短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
Znode的类型在创建时确定并且之后不能再修改
Znode有四种形式的目录节点
PERSISTENT
EPHEMERAL
PERSISTENT_SEQUENTIAL
EPHEMERAL_SEQUENTIAL

会话session
客户端与集群节点建立TCP连接后获得一个session
如果连接的Server出现问题，在没有超过Timeout时间时，可以连接其他节点
同一session期内的特性不变
Session是由谁来创建的？
Leader：产生一个唯一的session，放到消息队列，让所有server知道
（过半）
事件监听Watcher
Watcher 在 ZooKeeper 是一个核心功能，Watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目录节点上的Watcher，从而每个客户端都很快知道它所关注的目录节点的状态发生变化，而做出相应的反应
可以设置观察的操作：exists,getChildren,getData
可以触发观察的操作：create,delete,setData

回调client方法
业务核心代码在哪里？
	client

在这里插入图片描述
原子消息广播协议ZAB
cap
paxos
raft
zab
ZAB：
myid/serverID
zxid，
epoch
numID
模式：
恢复模式
无主，无服务
选举leader
广播模式
主从模式
leader维护事物的唯一和有序性
队列机制

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式：
	恢复模式
	广播模式。
当服务启动或者在领导者崩溃后
	Zab就进入了恢复模式，
	当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。
状态同步保证了leader和server具有相同的系统状态

广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。
所有的提议  (proposal)都在被提出的时候加上了zxid。
实现中zxid是一个64为的数字，它高32位是epoch用来标识  leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，低32位是个递增计数。

Paxos :
https://www.douban.com/note/208430424/
在这里插入图片描述
Leader选举：
首先，是在一种无主的模型下
毛遂自荐：自我投票
需要对事实，对黑白，对正反的自我判断
公开、公正、公平或者说准确的选出有能力者
公平竞争：zxid事务id最大的持有的数据最新
说出事实真相：传递投票
在这里插入图片描述

总结：
攘其外
主从模型
消息队列
zxid
数据模型：znode
事件通知：Watcher
session
必先：快速
安其内
无主模型
选举：
判定（zxid，myid）
投票传递性