ZooKeeper详细解析

1 Zookeeper简介
Zookeeper 是分布式服务框架,主要是用来解决分布式应用中常常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等等。
2 zookeeper基本概念
2.1角色
Zookeeper中的角色主要有如下三类,以下表所示:
id="iframe_0.41924588106270533" frameborder="0" scrolling="no" style="border-style:none;width:573px;">


系统模型如图所示:
id="iframe_0.0980927979309354" frameborder="0" scrolling="no" style="border-style:none;width:559px;">


2.2设计目的
1.最终一致性:client不论链接到哪一个Server,展现给它都是同一个视图,这是zookeeper最重要的性能。
2 .可靠性:具备简单、健壮、良好的性能,若是消息m被到一台服务器接受,那么它将被全部的服务器接受。
3 .实时性:Zookeeper保证客户端将在一个时间间隔范围内得到服务器的更新信息,或者服务器失效的信息。但因为网络延时等缘由,Zookeeper不能保证两个客户端能同时获得刚更新的数据,若是须要最新数据,应该在读数据以前调用sync()接口。
4 .等待无关(wait-free):慢的或者失效的client不得干预快速的client的请求,使得每一个client都能有效的等待。
5.原子性:更新只能成功或者失败,没有中间状态。
6 .顺序性:包括全局有序和偏序两种:全局有序是指若是在一台服务器上消息a在消息b前发布,则在全部Server上消息a都将在消息b前被发布;偏序是指若是一个消息b在消息a后被同一个发送者发布,a必将排在b前面。
3 zookeeper工做原理
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与之同步。
3.1 选主流程
当 leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式须要从新选举出一个新的leader,让全部的 Server都恢复到一个正确的状态。Zk的选举算法有两种:一种是基于basic paxos实现的,另一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
basic paxos流程:
1 .选举线程由当前Server发起选举的线程担任,其主要功能是对投票结果进行统计,并选出推荐的Server;
2 .选举线程首先向全部Server发起一次询问(包括本身);
3 .选举线程收到回复后,验证是不是本身发起的询问(验证zxid是否一致),而后获取对方的id(myid),并存储到当前询问对象列表中,最后获取对方提议的leader相关信息(id,zxid),并将这些信息存储到当次选举的投票记录表中;
4. 收到全部Server回复之后,就计算出zxid最大的那个Server,并将这个Server相关信息设置成下一次要投票的Server;
5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader,若是此时获胜的Server得到n/2 + 1的Server票数, 设置当前推荐的leader为获胜的Server,将根据获胜的Server相关信息设置本身的状态,不然,继续这个过程,直到leader被选举出来。
通 过流程分析咱们能够得出:要使Leader得到多数Server的支持,则Server总数必须是奇数2n+1,且存活的Server的数目不得少于 n+1.每一个Server启动后都会重复以上流程。在恢复模式下,若是是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信 息,zk会记录事务日志并按期进行快照,方便在恢复时进行状态恢复。
选主的具体流程图以下所示:
id="iframe_0.6319783807346231" frameborder="0" scrolling="no" style="border-style:none;width:471px;">


fast paxos流程是在选举过程当中,某Server首先向全部Server提议本身要成为leader,当其它Server收到提议之后,解决epoch和 zxid的冲突,并接受对方的提议,而后向对方发送接受提议完成的消息,重复这个流程,最后必定能选举出Leader。其流程图以下所示:
id="iframe_0.4834933463370752" frameborder="0" scrolling="no" style="border-style:none;width:533px;">

3.2同步流程
选完leader之后,zk就进入状态同步过程。
1. leader等待server链接;
2 .Follower链接leader,将最大的zxid发送给leader;
3 .Leader根据follower的zxid肯定同步点;
4 .完成同步后通知follower 已经成为uptodate状态;
5 .Follower收到uptodate消息后,又能够从新接受client的请求进行服务了。
流程图以下所示:
id="iframe_0.954320911148655" frameborder="0" scrolling="no" style="border-style:none;width:379px;">

3.3工做流程
3.3.1Leader工做流程
Leader主要有三个功能:
1 .恢复数据;
2 .维持与Learner的心跳,接收Learner请求并判断Learner的请求消息类型;
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根据不一样的消息类型,进行不一样的处理。
PING 消息是指Learner的心跳信息;REQUEST消息是Follower发送的提议信息,包括写请求及同步请求;ACK消息是Follower的对提议 的回复,超过半数的Follower经过,则commit该提议;REVALIDATE消息是用来延长SESSION有效时间。
Leader的工做流程简图以下所示:
id="iframe_0.38312274083714626" frameborder="0" scrolling="no" style="border-style:none;width:425px;">

3.3.2Follower工做流程
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结果到客户端,这个消息最初由客户端发起,用来强制获得最新的更新。
Follower的工做流程简图以下所示:
id="iframe_0.3926517562947809" frameborder="0" scrolling="no" style="border-style:none;width:555px;">

4 zookeeper安装配置
ZooKeeper的安装模式分为三种,分别为:单机模式(stand-alone)、集群模式和集群伪
分布模式。
4.1单机模式
下载zookeeper的安装包以后, 解压到合适目录. 进入zookeeper目录下的conf子目录, 建立zoo.cfg:
tickTime=2000 
dataDir=/Users/apple/zookeeper/data 
dataLogDir=/Users/apple/zookeeper/logs 
clientPort=4180 
参数说明:
tickTime: zookeeper中使用的基本时间单位, 毫秒值.
dataDir: 数据目录. 能够是任意目录.
dataLogDir: log目录, 一样能够是任意目录. 若是没有设置该参数, 将使用和dataDir相同的设置.
clientPort: 监听client链接的端口号
4.2伪集群模式
所谓伪集群, 是指在单台机器中启动多个zookeeper进程, 并组成一个集群. 以启动3个zookeeper进程为例.
将zookeeper的目录拷贝2份:
zookeeper0/conf/zoo.cfg文件为:
tickTime=2000 
initLimit=5 
syncLimit=2 
dataDir=/Users/apple/zookeeper0/data 
dataLogDir=/Users/apple/zookeeper0/logs 
clientPort=4180 
server.0=127.0.0.1:8880:7770 
server.1=127.0.0.1:8881:7771 
server.2=127.0.0.1:8882:7772 
新增了几个参数, 其含义以下:
1 initLimit: zookeeper集群中的包含多台server, 其中一台为leader, 集群中其他的server为follower. initLimit参数配置初始化链接时, follower和leader之间的最长心跳时间. 此时该参数设置为5, 说明时间限制为5倍tickTime, 即5*2000=10000ms=10s.
2 syncLimit: 该参数配置leader和follower之间发送消息, 请求和应答的最大时间长度. 此时该参数设置为2, 说明时间限制为2倍tickTime, 即4000ms.
3 server.X=A:B:C 其中X是一个数字, 表示这是第几号server. A是该server所在的IP地址. B配置该server和集群中的leader交换消息所使用的端口. C配置选举leader时所使用的端口. 因为配置的是伪集群模式, 因此各个server的B, C参数必须不一样.
参照zookeeper0/conf/zoo.cfg, 配置zookeeper1/conf/zoo.cfg, 和zookeeper2/conf/zoo.cfg文件. 只需更改dataDir, dataLogDir, clientPort参数便可.

在以前设置的dataDir中新建myid文件, 写入一个数字, 该数字表示这是第几号server. 该数字必须和zoo.cfg文件中的server.X中的X一一对应.
/Users/apple/zookeeper0/data/myid文件中写入0, /Users/apple/zookeeper1/data/myid文件中写入1, /Users/apple/zookeeper2/data/myid文件中写入2.

分别进入/Users/apple/zookeeper0/bin, /Users/apple/zookeeper1/bin, /Users/apple/zookeeper2/bin三个目录, 启动server.
4.3集群模式
集群模式的配置和伪集群基本一致.
因为集群模式下, 各server部署在不一样的机器上, 所以各server的conf/zoo.cfg文件能够彻底同样.
下面是一个示例:
tickTime=2000 
initLimit=5 
syncLimit=2 
dataDir=/home/zookeeper/data 
dataLogDir=/home/zookeeper/logs 
clientPort=4180 
server.43=10.1.39.43:2888:3888 
server.47=10.1.39.47:2888:3888 
server.48=10.1.39.48:2888:3888 
示 例中部署了3台zookeeper server, 分别部署在10.1.39.43, 10.1.39.47, 10.1.39.48上. 须要注意的是, 各server的dataDir目录下的myid文件中的数字必须不一样,10.1.39.43 server的myid为43, 10.1.39.47 server的myid为47, 10.1.39.48 server的myid为48.
5 zookeeper经常使用命令
ZooKeeper服务命令:
1. 启动ZK服务: ./zkServer.sh start
2. 查看ZK服务状态: ./zkServer.sh status
3. 中止ZK服务: ./zkServer.sh stop
4. 重启ZK服务: ./zkServer.sh restart
zk客户端命令:
ZooKeeper 命令行工具相似于Linux的shell环境,使用它能够对ZooKeeper进行访问,数据建立,数据修改等操做. 使用 zkCli.sh -server 127.0.0.1:2181 链接到 ZooKeeper 服务,链接成功后,系统会输出 ZooKeeper 的相关环境以及配置信息。
命令行工具的一些简单操做以下:
1. 显示根目录下、文件: ls / 使用 ls 命令来查看当前 ZooKeeper 中所包含的内容
2. 显示根目录下、文件: ls2 / 查看当前节点数据并能看到更新次数等数据
3. 建立文件,并设置初始内容: create /zk "test" 建立一个新的 znode节点“ zk ”以及与它关联的字符串
4. 获取文件内容: get /zk 确认 znode 是否包含咱们所建立的字符串
5. 修改文件内容: set /zk "zkbak" 对 zk 所关联的字符串进行设置
6. 删除文件: delete /zk 将刚才建立的 znode 删除
7. 退出客户端: quit
8. 帮助命令: help
ZooKeeper 经常使用四字命令:
ZooKeeper 支持某些特定的四字命令字母与其的交互。它们大可能是查询命令,用来获取 ZooKeeper 服务的当前状态及相关信息。用户在客户端能够经过 telnet 或 nc 向 ZooKeeper 提交相应的命令
1. 能够经过命令:echo stat|nc 127.0.0.1 2181 来查看哪一个节点被选择做为follower或者leader
2. 使用echo ruok|nc 127.0.0.1 2181 测试是否启动了该Server,若回复imok表示已经启动。
3. echo dump| nc 127.0.0.1 2181 ,列出未经处理的会话和临时节点。
4. echo kill | nc 127.0.0.1 2181 ,关掉server
5. echo conf | nc 127.0.0.1 2181 ,输出相关服务配置的详细信息。
6. echo cons | nc 127.0.0.1 2181 ,列出全部链接到服务器的客户端的彻底的链接 / 会话的详细信息。
7. echo envi |nc 127.0.0.1 2181 ,输出关于服务环境的详细信息(区别于 conf 命令)。
8. echo reqs | nc 127.0.0.1 2181 ,列出未经处理的请求。
9. echo wchs | nc 127.0.0.1 2181 ,列出服务器 watch 的详细信息。
10. echo wchc | nc 127.0.0.1 2181 ,经过 session 列出服务器 watch 的详细信息,它的输出是一个与 watch 相关的会话的列表。
11. echo wchp | nc 127.0.0.1 2181 ,经过路径列出服务器 watch 的详细信息。它输出一个与 session 相关的路径。