一、ZooKeeper 是什么?html
Zookeeper官网地址: http://zookeeper.apache.org/node
Zookeeper官网文档地址:http://zookeeper.apache.org/doc/trunk/index.html算法
ZooKeeper 是Hadoop下的一个子项目,它是一个针对大型分布式系统的可靠协调系统;它提供的功能包括:配置维护、名字服务、分布式同步、组服务等; 它的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。数据库
Zookeeper一个最经常使用的使用场景就是用于担任服务生产者和服务消费者的注册中心,服务生产者将本身提供的服务注册到Zookeeper中心,服务的消费者在进行服务调用的时候先到Zookeeper中查找服务,获取到服务生产者的详细信息以后,再去调用服务生产者的内容与数据,简单示例图以下:apache
二、ZooKeeper设计目标:性能优化
ZooKeeper容许分布式进程经过共享的层次结构命名空间进行相互协调,这与标准文件系统相似。 名称空间由ZooKeeper中的数据寄存器组成 - 称为znode,这些相似于文件和目录。 与为存储设计的典型文件系统不一样,ZooKeeper数据保存在内存中,这意味着ZooKeeper能够实现高吞吐量和低延迟。服务器
Zookeeper层次结构命名空间示意图以下:架构
经过这种树图结构的数据模型,很容易的查找到具体的某一个服务。分布式
三、ZooKeeper主要特色:oop
1)、最终一致性:为客户端展现同一视图,这是 ZooKeeper 最重要的性能。
2)、可靠性:若是消息被一台服务器接受,那么它将被全部的服务器接受。
3)、实时性:ZooKeeper 不能保证两个客户端同时获得刚更新的数据,若是须要最新数据,应该在读数据以前调用sync()接口。
4)、等待无关(wait-free):慢的或者失效的 client 不干预快速的client的请求。
5)、原子性:更新只能成功或者失败,没有中间其它状态。
6)、顺序性:对于全部Server,同一消息发布顺序一致。
一、ZooKeeper 系统架构
首先看一下 ZooKeeper 的架构图。
ZooKeeper 的架构图中咱们须要了解和掌握的主要有:
(1)ZooKeeper分为服务器端(Server) 和客户端(Client),客户端能够链接到整个 ZooKeeper服务的任意服务器上(除非 leaderServes 参数被显式设置, leader 不容许接受客户端链接)。
(2)客户端使用并维护一个 TCP 链接,经过这个链接发送请求、接受响应、获取观察的事件以及发送心跳。若是这个 TCP 链接中断,客户端将自动尝试链接到另外的 ZooKeeper服务器。客户端第一次链接到 ZooKeeper服务时,接受这个链接的 ZooKeeper服务器会为这个客户端创建一个会话。当这个客户端链接到另外的服务器时,这个会话会被新的服务器从新创建。
(3)上图中每个Server表明一个安装Zookeeper服务的机器,便是整个提供Zookeeper服务的集群(或者是由伪集群组成);
(4)组成ZooKeeper服务的服务器必须彼此了解。 它们维护一个内存中的状态图像,以及持久存储中的事务日志和快照, 只要大多数服务器可用,ZooKeeper服务就可用;
(5)ZooKeeper 启动时,将从实例中选举一个 leader,Leader 负责处理数据更新等操做,一个更新操做成功的标志是当且仅当大多数Server在内存中成功修改数据。每一个Server 在内存中存储了一份数据。
(6)Zookeeper是能够集群复制的,集群间经过Zab协议(Zookeeper Atomic Broadcast)来保持数据的一致性;
(7)Zab协议包含两个阶段:leader election阶段和Atomic Brodcast阶段。
a) 集群中将选举出一个leader,其余的机器则称为follower,全部的写操做都被传送给leader,并经过brodcast将全部的更新告诉给follower。
b) 当leader崩溃或者leader失去大多数的follower时,须要从新选举出一个新的leader,让全部的服务器都恢复到一个正确的状态。
c) 当leader被选举出来,且大多数服务器完成了 和leader的状态同步后,leadder election 的过程就结束了,就将会进入到Atomic brodcast的过程。
d) Atomic Brodcast同步leader和follower之间的信息,保证leader和follower具备形同的系统状态。
二、Zookeeper 角色
启动 Zookeeper 服务器集群环境后,多个 Zookeeper 服务器在工做前会选举出一个 Leader。选举出 leader 前,全部 server 不区分角色,都须要平等参与投票( obServer 除外,不参与投票);
选主过程完成后,存在如下几种角色:
思考:
一、为何须要server?
①ZooKeeper 需保证高可用和强一致性;
②为了支持更多的客户端,须要增长更多的Server;
③Follower增多会致使投票阶段延迟增大,影响性能。 123123
2、在Zookeeper 中ObServer 起到什么做用?
①ObServer 不参与投票过程,只同步 leader的状态 ;
②Observers 接受客户端的链接,并将写请求转发给 leader节点 ;
③加入更多ObServer 节点,提升伸缩性,同时还不影响吞吐率。123123
3、为何在Zookeeper中Server 数目通常为奇数?
咱们知道在Zookeeper中 Leader 选举算法采用了Zab协议。Zab核心思想是当多数 Server 写成功,则任务数据写成功。
①若是有3个Server,则最多容许1个Server 挂掉。
②若是有4个Server,则一样最多容许1个Server挂掉。
既然3个或者4个Server,一样最多容许1个Server挂掉,那么它们的可靠性是同样的,因此选择奇数个ZooKeeper Server便可,这里选择3个Server。
三、ZooKeeper 写数据流程
ZooKeeper 写数据的流程图以下所示。
ZooKeeper 的写数据流程主要分为如下几步:
a)、好比 Client 向 ZooKeeper 的 Server1 上写数据,发送一个写请求。
b)、若是Server1不是Leader,那么Server1 会把接受到的请求进一步转发给Leader,由于每一个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server,好比Server1和Server2, 各个Server写成功后就会通知Leader。
c)、当Leader收到大多数 Server 数据写成功了,那么就说明数据写成功了。若是这里三个节点的话,只要有两个节点数据写成功了,那么就认为数据写成功了。写成功以后,Leader会告诉Server1数据写成功了。
d)、Server1会进一步通知 Client 数据写成功了,这时就认为整个写操做成功。
四、ZooKeeper 组件
ZooKeeper组件显示了ZooKeeper服务的高级组件。 除了请求处理器,组成ZooKeeper服务的每一个服务器复制其本身的每一个组件的副本。
Replicated Database是包含整个数据树的内存数据库。 更新操做会记录到磁盘里以进行可恢复性,而且写操做将在放到内存数据库以前序列化到磁盘。
每一个ZooKeeper服务器服务客户端。 客户端链接到一个服务器以提交irequest。 读取请求从每一个服务器数据库的本地副本服务。 更改服务状态(写入请求)的请求由协议进行处理。
做为协议协议的一部分,来自客户端的全部写请求被转发到单个服务器,称为leader。 其他的ZooKeeper服务器(称为followers)从领导者接收消息提议并赞成消息传递。 消息层负责在失败时替换领导者,并与leader同步followers。
一、统一命名服务
统一命名服务的命名结构图以下所示:
一、在分布式环境下,常常须要对应用/服务进行统一命名,便于识别不一样服务。
a)相似于域名与ip之间对应关系,ip不容易记住,而域名容易记住。
b)经过名称来获取资源或服务的地址,提供者等信息。
二、按照层次结构组织服务/应用名称。
a)可将服务名称以及地址信息写到ZooKeeper上,客户端经过ZooKeeper获取可用服务列表类。
二、配置管理
配置管理结构图以下所示:
一、分布式环境下,配置文件管理和同步是一个常见问题。
a)一个集群中,全部节点的配置信息是一致的,好比 Hadoop 集群。
b)对配置文件修改后,但愿可以快速同步到各个节点上。
二、配置管理可交由ZooKeeper实现。
a)可将配置信息写入ZooKeeper上的一个Znode。
b)各个节点监听这个Znode。
c)一旦Znode中的数据被修改,ZooKeeper将通知各个节点。
三、集群管理
集群管理结构图以下所示:
一、分布式环境中,实时掌握每一个节点的状态是必要的。
a)可根据节点实时状态作出一些调整。
二、可交由ZooKeeper实现。
a)可将节点信息写入ZooKeeper上的一个Znode。
b)监听这个Znode可获取它的实时状态变化。
三、典型应用
a)Hbase中Master状态监控与选举。
四、分布式通知与协调
一、分布式环境中,常常存在一个服务须要知道它所管理的子服务的状态。
a)NameNode需知道各个Datanode的状态。
b)JobTracker需知道各个TaskTracker的状态。
二、心跳检测机制可经过ZooKeeper来实现。
三、信息推送可由ZooKeeper来实现,ZooKeeper至关于一个发布/订阅系统。
五、分布式锁
处于不一样节点上不一样的服务,它们可能须要顺序的访问一些资源,这里须要一把分布式的锁。
分布式锁具备如下特性:
一、ZooKeeper是强一致的。好比各个节点上运行一个ZooKeeper客户端,它们同时建立相同的Znode,可是只有一个客户端建立成功。
二、实现锁的独占性。建立Znode成功的那个客户端才能获得锁,其它客户端只能等待。当前客户端用完这个锁后,会删除这个Znode,其它客户端再尝试建立Znode,获取分布式锁。
三、控制锁的时序。各个客户端在某个Znode下建立临时Znode,这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL,这样该Znode可掌握全局访问时序。
六、分布式队列
分布式队列分为两种:
一、当一个队列的成员都聚齐时,这个队列才可用,不然一直等待全部成员到达,这种是同步队列。
a)一个job由多个task组成,只有全部任务完成后,job才运行完成。
b)可为job建立一个/job目录,而后在该目录下,为每一个完成的task建立一个临时的Znode,一旦临时节点数目达到task总数,则代表job运行完成。
二、队列按照FIFO方式进行入队和出队操做,例如实现生产者和消费者模型。
zookeeper 的安装模式有三种:
单机模式( stand-alone):单机单 server;
集群模式:多机多 server,造成集群;
伪集群模式:单机多个 server,造成伪集群;
环境:Cent OS 7.0
一、单机模式
(1)根据须要建立目录,例如个人目录是:/home/xuliugen/Desktop/zookeeper-install
(2)进入目录,使用wget下载zookeeper,
下载地址:https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
其余版本下载地址:https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/
完成以下:
(3)使用: tar -xvf zookeeper-3.4.6.tar.gz
解压缩该文件;
(4)建立Zookeeper配置文件:
在Zookeeper的安装目录下的conf文件下,默认为:
使用:cp zoo_sample.cfg zoo.cfg
命令,复制一份为zoo.cfg文件,这是由于Zookeeper再启动的时候默认使用的是zoo.cfg这个配置文件。
(5)根据需求修改配置文件内容:
通常默认的配置文件就能够演示启动,配置文件以下:
小提示:
在Zookeeper官方文档中给了一个关于性能优化的小经验,就是有几个其余配置参数能够大大提升性能:
为了得到更新时的低延迟,重要的是有一个专用的事务日志目录。 默认状况下,事务日志与数据快照和myid文件放在同一目录中。 dataLogDir参数指示用于事务日志的不一样目录。
意思就是说,最好将属具目录和日志目录分离开来,从而提升数据的读取更新效率。
(6)启动Zookeeper
在Zookeeper安装目录的bin目录下:
使用命令:./zkServer.sh start
便可开启服务:
使用: ./zkCli.sh
命令能够进入到命令行管理界面:
到此单机模式就安装结束了!
二、集群模式 三、伪集群模式
关于集群模式 和伪集群模式的配置,网上已经有不少内容,这里再也不演示,请移步查看:
http://www.open-open.com/lib/view/open1454043410245.html
zoo.cfg配置参数解释:
参考文章:
一、《大型分布式网站架构-设计与实践 陈康贤-著》
二、《Zookeeper-3.3.5源码分析 刘少伟》
三、http://m.blog.csdn.net/article/details?id=51209939
四、http://mt.sohu.com/20160527/n451709612.shtml
五、http://www.open-open.com/lib/view/open1454043410245.html