zookeeper官网:http://zookeeper.apache.org/

介绍

zookeeper是一个 分布式的,开源的分布式应用程序协调服务,是Google的Chubby开源的实现,是 Hadoop和Hbase的重要组件。

作用

为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

特性

  • 最终一致性:为客户端展示同一视图,这是Zookeeper最重要的性能;
  • 可靠性:如果消息被一台服务器接受,那么它将被所有的服务器接受;
  • 原子性:更新只能成功或失败,没有中间状态;

应用场景

  1. 统一命名服务
    (1)分布式环境下,经常需要对应用/服务进行统一命名,便于识别不同的服务
    类似于域名与ip之间对应关系,域名容易记住;
    通过名称来获取资源或服务的地址,提供者信息。
    (2)按照层次结构组织服务/应用名称
    可将服务名称以及地址信息写在Zookeeper上,客户端通过Zookeeper获取可用服务列表。

  2. 配置管理
    (1)分布式环境下,配置文件管理和同步是一个常见问题
    一个集群中,所有节点的配置信息是一致的,比如Hadoop;
    对配置文件修改后,希望能够快速同步到各个节点上。
    (2)配置管理可交由Zookeeper实现
    可将配置信息写入Zookeeper的一个znode上;
    各个节点监听这个znode
    一旦znode中的数据被修改,Zookeeper将会通知各个节点。

  3. 集群管理
    (1)分布式环境下,实时掌握每个节点的状态是必要的
    可根据节点实时状态做出一些调整。
    (2)可交由Zookeeper实现
    可将节点信息写入Zookeeper的一个znode上;
    监听这个znode可获得它的实时状态变化。
    (3)典型应用
    HBase中Master状态的监控与选举。

  4. 分布式通知/协调
    原理其实就是发布/订阅。
    (1)分布式环境下经常存在一个服务需要知道它所管理的子服务的状态
    NameNode需要知道各DataNode的状态
    (2)心跳检测机制可通过Zookeeper实现
    (3)信息推送可由Zookeeper实现(发布/订阅模式)

  5. 分布式锁
    (1)Zookeeper是强一致性的
    多个客户端同时在Zookeeper上创建相同znode,只有一个创建成功。
    (2)实现锁的独占性
    多个客户端同时在Zookeeper上创建相同znode,创建成功的那个客户端得到锁,其他客户端等待。
    (3)控制锁的时序

各个客户端在某个znode下创建临时znode(类型为CreateMode.EPHEMERAL_SEQUENTIAL),这样,该znode可掌握全局访问时序。

集群部署

安装部署分三种模式:单机模式、伪分布式模式和分布式模式。单机模式和伪分布式比较简单,多用于本地测试调试,下面介绍分布式模式安装部署。

环境准备

1、准备3台linux主机,对于Zookeeper集群的话,官方推荐的最小节点数为3个。
2、安装JDK

安装

1、官网下载tar包zookeeper-3.4.9.tar.gz
2、解压

tar zxvf zookeeper-3.4.9.tar.gz

3、进入conf目录,修改zoo_sample.cfg文件名为zoo.cfg(zoo默认配置)

mv zoo_sample.cfg zoo.cfg

4、修改 zoo.cfg文件配置

vi zoo.cfg

#存放数据文件
dataDir=/usr/local/zookeeper-3.4.6/dataDir

#存放日志文件
dataLogDir=/usr/local/zookeeper-3.4.6/dataLogDir

#客户端连接端口
clientPort=2181

#zookeeper cluster,ip:port1为服务端通讯端口,por2为选举端口
​ps:伪集群部署端口号需不一样
server.1=ip:port1:por2
server.2=ip:port1:por2
server.3=ip:port1:por2

zoo.cfg 配置参数详解:

  • tickTime:tick时长
  • syncLimit:Leader和follower之间的通讯时长 最长不能超过initLimt*ticktime
  • initLimt:接受客户端链接zk初始化的最长等待心跳时长 initLimt*ticktime
  • dataDir:数据目录
  • dataLogDir:日志文件
  • clientPort:客户端链接服务端端口号
  • Server.A=B:C:D :A:第几号服务器 B服务IP
    C代表Leader和follower通讯端口 D备用选leader端口

5、创建data及日志目录

mkdir /usr/local/zookeeper-3.4.6/dataDir
mkdir /usr/local/zookeeper-3.4.6/dataLogDir

6、在我们配置的dataDir指定的目录下面,创建一个myid文件,
​里面内容为一个数字,用来标识当前主机,
​conf/zoo.cfg文件中配置的server.X中X为什么数字,则myid文件中就输入这个数字:

 echo "1" > /usr/local/zookeeper-3.4.6/dataDir/myid 

7、相同步骤配置另外两台机子
8、启动,bin目录下

./zkServer.sh start 

9、测试

  ./zkServer.sh status

成功
在这里插入图片描述

集群角色介绍

Leader:
Leader作为整个ZooKeeper集群的主节点,负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号,以便保证整个集群内部消息处理的FIFO,写操作都走leader,zk里面leader只有一个。

Follower :
Follower的逻辑就比较简单了。除了响应本服务器上的读请求外,follower还要处理leader的提议,并在leader提交该提议时在本地也进行提交。 另外需要注意的是,leader和follower构成ZooKeeper集群的法定人数,也就是说,只有他们才参与新leader的选举、响应leader的提议。 帮助leader处理读请求,没有写请求,投票权。

Observer :
如果ZooKeeper集群的读取负载很高,或者客户端多到跨机房,可以设置一些observer服务器,以提高读取的吞吐量。Observer和Follower比较相似,只有一些小区别:首先observer不属于法定人数,即不参加选举也不响应提议;其次是observer不需要将事务持久化到磁盘,一旦observer被重启,需要从leader重新同步整个名字空间。 没有投票权利,可以处理读请求,没有写请求

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐