Zookeeper部署介绍上

原创
2017/02/18 12:02
阅读数 29

什么是Zookeeper?

Zookeeper 是 Google 的 Chubby一个开源的实现,是 Hadoop 的分布式协调服务 它包含一个简单的原语集,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等

为什么使用Zookeeper?

大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程(如资源、任务分配等) 目前,大部分应用需要开发私有的协调程序,缺乏一个通用的机制 协调程序的反复编写浪费,且难以形成通用、伸缩性好的协调器 ZooKeeper:提供通用的分布式锁服务,用以协调分布式应用

Zookeeper能帮我们做什么?

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

Zookeeper的特性

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

Zookeeper的安装和配置(单机模式)

下载ZooKeeper:http://labs.renren.com/apache-mirror/zookeeper/zookeeper-3.4.3/zookeeper-3.4.3.tar.gz 解压:tar xzf zookeeper-3.4.3.tar.gz 在conf目录下创建一个配置文件zoo.cfg,tickTime=2000 dataDir=/Users/zdandljb/zookeeper/data dataLogDir=/Users/zdandljb/zookeeper/dataLog         clientPort=2181 启动ZooKeeper的Server:sh bin/zkServer.sh start, 如果想要关闭,输入:zkServer.sh stop

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

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

建了3个文件夹,server1 server2 server3,然后每个文件夹里面解压一个zookeeper的下载包 进入data目录,创建一个myid的文件,里面写入一个数字,server1,就写一个1,server2对应myid文件就写入2,server3对应myid文件就写个3

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

Zookeeper的数据模型

层次化的目录结构,命名符合常规文件系统规范 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识 节点Znode可以包含数据和子节点,但是EPHEMERAL类型的节点不能有子节点 Znode中的数据可以有多个版本,比如某一个路径下存有多个数据版本,那么查询这个路径下的数据就需要带上版本 客户端应用可以在节点上设置监视器 节点不支持部分读写,而是一次性完整读写

Zookeeper的节点

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

Zookeeper的角色

领导者(leader),负责进行投票的发起和决议,更新系统状态 学习者(learner),包括跟随者(follower)和观察者(observer),follower用于接受客户端请求并想客户端返回结果,在选主过程中参与投票 Observer可以接受客户端连接,将写请求转发给leader,但observer不参加投票过程,只同步leader的状态,observer的目的是为了扩展系统,提高读取速度 客户端(client),请求发起方

Zookeeper的顺序号

创建znode时设置顺序标识,znode名称后会附加一个值 顺序号是一个单调递增的计数器,由父节点维护 在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序

Zookeeper的读写机制

Zookeeper是一个由多个server组成的集群 一个leader,多个follower 每个server保存一份数据副本 全局数据一致 分布式读写 更新请求转发,由leader实施

Zookeeper的保证

更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行 数据更新原子性,一次数据更新要么成功,要么失败 全局唯一数据视图,client无论连接到哪个server,数据视图都是一致的 实时性,在一定事件范围内,client能读到最新数据

Zookeeper的API接口

String create(String path, byte[] data, List<ACL> acl, CreateMode createMode)

Stat exists(String path, boolean watch)

void delete(String path, int version) List<String> g

etChildren(String path, boolean watch) List<String> getChildren(String path, boolean watch)

Stat setData(String path, byte[] data, int version) byte[]

getData(String path, boolean watch, Stat stat)

void addAuthInfo(String scheme, byte[] auth)

Stat setACL(String path, List<ACL> acl, int version)

List<ACL> getACL(String path, Stat stat)

写操作与zookeeper内部事件的对应关系

Zookeeper工作原理    

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

一旦leader已经和多数的follower进行了状态同步后,他就可以开始广播消息了,即进入广播状态。这时候当一个server加入zookeeper服务中,它会在恢复模式下启动,发现leader,并和leader进行状态同步。待到同步结束,它也参与消息广播。Zookeeper服务一直维持在Broadcast状态,直到leader崩溃了或者leader失去了大部分的followers支持。

Leader选举

广播模式需要保证proposal被按顺序处理,因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch。低32位是个递增计数。 当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的server都恢复到一个正确的状态。

每个Server启动以后都询问其它的Server它要投票给谁。 对于其他server的询问,server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid(系统启动时每个server都会推荐自己) 收到所有Server回复以后,就计算出zxid最大的哪个Server,并将这个Server相关信息设置成下一次要投票的Server。 计算这过程中获得票数最多的的sever为获胜者,如果获胜者的票数超过半数,则改server被选为leader。否则,继续这个过程,直到leader被选举出来。

leader就会开始等待server连接 Follower连接leader,将最大的zxid发送给leader Leader根据follower的zxid确定同步点 完成同步后通知follower 已经成为uptodate状态 Follower收到uptodate消息后,又可以重新接受client的请求进行服务了

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部