zookeeper-详述

时间:2019-12-17
本文章向大家介绍zookeeper-详述,主要包括zookeeper-详述使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

为什么使用Zookeeper?

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

zookeeper优点

特点 说明
最终一致性 为客户端展示同一个视图,这是zookeeper里面一 个非常重要的功能
可靠性 如果消息被到一台服务器接受,那么它将被所有的 服务器接受。
实时性 Zookeeper不能保证两个客户端能同时得到刚更新 的数据,如果需要最新数据,应该 在读数据之前调 用sync()接口。
独立性 各个Client之间互不干预 原子性 更新只能成功或者失败,没有中间状态。
顺序性 所 有Server,同一消息发布顺序一致。

zookeeper的工作原理,

1.每个Server在内存中存储了一份数据;
2.Zookeeper启动时,将从实例中选举一个leader(Paxos 协议)
3.Leader负责处理数据更新等操作
4.一个更新操作成功,当且仅当大多数Server在内存中成功修 改数据

zookeeper能帮我们做什么?

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

zookeeper的特性

1、Zookeeper是简单的
2、Zookeeper是富有表现力的
3、Zookeeper具有高可用性
4、Zookeeper采用松耦合交互方式
5、Zookeeper是一个资源库

Zookeeper的安装和配置(集群模式)

创建myid文件,server1机器的内容为:1,

server2 机器的内容为:2,

server3机器的内容为:3 ,

在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

tickTime:发送心跳的间隔时间,单位:毫秒 • dataDir:zookeeper保存数据的目录。 • clientPort:客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客 户端的访问请求。 • initLimit: 这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连 接 Zookeeper 服务器的客户端,而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的 时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息,那么表 明这个客户端连接失败。总的时间长度就是 52000=10 秒 • syncLimit:这个配置项标识 Leader 与 Follower 之间发送消息,请求和应答时间长度,最 长不能超过多少个 tickTime 的时间长度,总的时间长度就是 22000=4 秒 • server.A=B:C:D:其 中 A 是一个数字,表示这个是第几号服务器;B 是这个服务器的 ip 地址;C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口;D 表示的是万一 集群中的 Leader 服务器挂了,需要一个端口来重新进行选举,选出一个新的 Leader,而这 个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式,由于 B 都是 一样,所以不同的 Zookeeper 实例通信端口号不能一样,所以要给它们分配不同的端口号
1、领导者(leader),负责进行投票的发起和决议,更 新系统状态
2、学习者(learner),包括跟随者(follower)和观察 者(observer),follower用于接受客户端请求并想 客户端返回结果,在选主过程中参与投票 ,Observer可以接受客户端连接,将写请求转发给 leader,但observer不参加投票过程,只同步leader 的状态,observer的目的是为了扩展系统,提高读取 速度
3、客户端(client),请求发起

原子广播模式

Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协 议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者 崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和leader的状态同步以后 ,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
• 为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议( proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识 leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的 统治时期。低32位用于递增计数。
• 每个Server在工作过程中有三种状态:
• LOOKING:当前Server不知道leader是谁,正在搜寻
• LEADING:当前Server即为选举出来的leader
• FOLLOWING:leader已经选举出来,当前Server与之同步

zookeeper读写机制

1、Zookeeper是一个由多个server组成的集群
2、一个leader,多个follower
3、 每个server保存一份数据副本 » 全局数据一致
4、 分布式读写 » 更新请求转发,由leader实施
5、 更新请求顺序进行,来自同一个client的更新请求按其 发送顺序依次执行
6、 数据更新原子性,一次数据更新要么成功,要么失败
7、 全局唯一数据视图,client无论连接到哪个server,数据 视图都是一致的
8、实时性,在一定事件范围内,client能读到最新数据

Follower主要有四个功能:

  1. 向Leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消 息);
    2 .接收Leader消息并进行处理;
    3 .接收Client的请求,如果为写请求,发送给Leader进行投票;
    4 .返回Client结果。
    Follower的消息循环处理如下几种来自Leader的消息:
    1 .PING消息: 心跳消息;
    2 .PROPOSAL消息:Leader发起的提案,要求Follower投票;
    3 .COMMIT消息:服务器端最新一次提案的信息;
    4 .UPTODATE消息:表明同步完成;
    5 .REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的 session还是允许其接受消息;
    6 .SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制 得到最新的更新;

Zookeeper leader选举

半数通过 – 3台机器 挂一台 2>3/2 – 4台机器 挂2台 2!>4/2
1、A提案说,我要选自己,B你同意吗?C你同意吗?B说,我同意选A;C说,我同意选A。(注 意,这里超过半数了,其实在现实世界选举已经成功了。但是计算机世界是很严格,另外要 理解算法,要继续模拟下去。)
2、接着B提案说,我要选自己,A你同意吗;A说,我已经超半数同意当选,你的提案无效;C 说,A已经超半数同意当选,B提案无效。 • 接着C提案说,我要选自己,A你同意吗;A说,我已经超半数同意当选,你的提案无效;B 说,A已经超半数同意当选,C的提案无效。
3、选举已经产生了Leader,后面的都是follower,只能服从Leader的命令。而且这里还有个小 细节,就是其实谁先启动谁当头

zxid

1、znode节点的状态信息中包含czxid, 那么什么是zxid呢?
2、ZooKeeper状态的每一次改变, 都对应着一个递增的 Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果 zxid1小于zxid2, 那么zxid1肯定先于zxid2发生. 创建任意节点 , 或者更新任意节点的数据, 或者删除任意节点, 都会导致 Zookeeper状态发生改变, 从而导致zxid的值增加.
3、Zookeeper的核心是原子广播,这个机制保证了各个 server之间的同步。实现这个机制的协议叫做Zab协 议。Zab协议有两种模式,它们分别是恢复模式和广 播模式。当服务启动或者在领导者崩溃后,Zab就进 入了恢复模式,当领导者被选举出来,且大多数 server的完成了和leader的状态同步以后,恢复模式 就结束了。状态同步保证了leader和server具有相同 的系统状态。

Paxos数据一致性

据说Paxos算法的难理解与算法的知名度一样令人敬仰,所以我们先看如何保持数据的一致性,这里有个原则就是:
1、在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致 的状态。
2、 Paxos算法解决的什么问题呢,解决的就是保证每个节点执行相同的操作序列。好吧,这还不简单,master维护一个 全局写队列,所有写操作都必须 放入这个队列编号,那么无论我们写多少个节点,只要写操作是按编号来的,就能保证一 致性。没错,就是这样,可是如果master挂了呢。
3、 Paxos算法通过投票来对写操作进行全局编号,同一时刻,只有一个写操作被批准,同时并发的写操作要去争取选票, 只有获得过半数选票的写操作才会被 批准(所以永远只会有一个写操作得到批准),其他的写操作竞争失败只好再发起一 轮投票,就这样,在日复一日年复一年的投票中,所有写操作都被严格编号排 序。编号严格递增,当一个节点接受了一个 编号为100的写操作,之后又接受到编号为99的写操作(因为网络延迟等很多不可预见原因),它马上能意识到自己 数据 不一致了,自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性(总2n+1台,除非挂 掉大于n台)。
4、 总结 Zookeeper 作为 Hadoop 项目中的一个子项目,是 Hadoop 集群管理的一个必不可少的模块,它主要用来控制集群 中的数据,如它管理 Hadoop 集群中的 NameNode,还有 Hbase 中 Master Election、Server 之间状态同步等。
更生动的例子参考:屁民的故事

zookeeper节点

1、 Znode有两种类型,短暂的(ephemeral)和持久的(persistent)
2、 Znode的类型在创建时确定并且之后不能再修改 » 短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短 暂znode不可以有子节点 » 持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode 时才会被删除

Znode有四种形式的目录节点

1、 PERSISTENT (永久节点)
2、 EPHEMERAL(临时节点)
3、 PERSISTENT_SEQUENTIAL(永久有序节点)
4、 EPHEMERAL_SEQUENTIAL(临时有序节点)

Watcher

Watcher 在 ZooKeeper 是一个核心功能,Watcher 可以 监控目录节点的数据变化以及子目录的变化,一旦这 些状态发生变化,服务器就会通知所有设置在这个目 录节点上的 Watcher,从而每个客户端都很快知道它所 关注的目录节点的状态发生变化,而做出相应的反应 ; 可以设置观察的操作:exists,getChildren,getData ;可以触发观察的操作:create,delete,setData



原文地址:https://www.cnblogs.com/BruceV/p/12055626.html