-
less zoo.cfg
-
# The number of milliseconds of each tick
-
tickTime=2000
-
#CS通信心跳数,服务器之间或客户端与服务器之间间隔多久发送一个心跳
-
#tickTime以毫秒为单位。
-
# The number of ticks that the initial
-
# synchronization phase can take
-
initLimit=10
-
#initLimit:Leader与Follower初始通信时限
#集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数(tickTime的数量)。 -
# The number of ticks that can pass between
-
# sending a request and getting an acknowledgement
-
syncLimit=5
-
#syncLimit:Leader与Follower同步通信时限
#集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数(tickTime的数量)。 -
# 3.4.0 版本后引入了数据自动清理功能
-
autopurge.purgeInterval=1 (zookeeper自动清理间隔,单位小时)
-
autopurge.snapRetainCount=10 (保留快照文件个数)
-
# the directory where the snapshot is stored.
-
dataDir=/data/appdatas/zookeeper
-
Zookeeper保存数据的目录,默认情况下,Zookeeper将写数据的日志文件也保存在这个目录里。
-
#commitLog数据存储
-
dataLogDir=/data/applogs/zookeeper
-
Zookeeper保存日志文件的目录。
-
# the port at which the clients will connect
-
clientPort=2181
-
#客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。
-
# znode
-
#zookeeper 集群信息(服务器编号,服务器地址,Leader与Follower通信端口,选举端口)
-
#选举端口,表示选举新leader时服务器间相互通信的端口(当leader挂掉时,其余服务器会相互通信,选择出新的leader)
-
server.1(myid文件,dataDir目录中)=101.1.2.132:2888:3888
-
#servers making up the ZooKeeper ensemble. When the server starts up, it determines which server it is by looking for the file myid in the data directory. That file contains the server number, in ASCII, and it should match x in server.x in the left hand side of this setting.
-
server.2=101.1.2.137:2888:3888
-
server.3=101.1.2.162:2888:3888
-
server.4=101.1.2.167:2888:3888
-
server.5=101.1.2.158:2888:3888
mkdir -p /package
chmod 1755 /package
cd /package
wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
tar -zxvf daemontools-0.76.tar.gz
cd admin/daemontools-0.76
package/install
1
2
3
4
|
#!/bin/bash
.
/etc/profile
exec
2>&1
exec
/data/webapps/zookeeper/bin/zkServer
.sh start-foreground
|
zookeeper的基本概念
角色
设计目的
-
每个子目录项如 NameService 都被称作为 znode,这个 znode 是被它所在的路径唯一标识,如 Server1 这个 znode 的标识为 /NameService/Server1
-
znode 可以有子节点目录,并且每个 znode 可以存储数据,注意 EPHEMERAL 类型的目录节点不能有子节点目录
-
znode 是有版本的,每个 znode 中存储的数据可以有多个版本,也就是一个访问路径中可以存储多份数据
-
znode 可以是临时节点,一旦创建这个 znode 的客户端与服务器失去联系,这个 znode 也将自动删除,Zookeeper 的客户端和服务器通信采用长连接方式,每个客户端和服务器通过心跳来保持连接,这个连接状态称为 session,如果 znode 是临时节点,这个 session 失效,znode 也就删除了
-
znode 的目录名可以自动编号,如 App1 已经存在,再创建的话,将会自动命名为 App2
-
znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端
工作原理
-
LOOKING:当前Server不知道leader是谁,正在搜寻
-
LEADING:当前Server即为选举出来的leader
-
FOLLOWING:leader已经选举出来,当前Server与之同步
-
Leader选举流程:
-
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被选举出来。
zookeeper数据同步过程:
-
1. leader等待server连接;
-
2 .Follower连接leader,将最大的zxid发送给leader;
-
3 .Leader根据follower的zxid确定同步点;
-
4 .完成同步后通知follower 已经成为uptodate状态;
-
5 .Follower收到uptodate消息后,又可以重新接受client的请求进行服务了。
工作流程
Leader工作流程
-
1 .恢复数据;
-
2 .维持与Learner的心跳,接收Learner请求并判断Learner的请求消息类型;
-
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根据不同的消息类型,进行不同的处理。
2.3.2 Follower工作流程
-
1. 向Leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
-
2 .接收Leader消息并进行处理;
-
3 .接收Client的请求,如果为写请求,发送给Leader进行投票;
-
4 .返回Client结果。
-
1 .PING消息:心跳消息;
-
2 .PROPOSAL消息:Leader发起的提案,要求Follower投票;
-
3 .COMMIT消息:服务器端最新一次提案的信息;
-
4 .UPTODATE消息:表明同步完成;
-
5 .REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的session还是允许其接受消息;
-
6 .SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。
本文转载自 “运维者说:从菜鸟到老鸟” 博客,http://liuqunying.blog.51cto.com/3984207/1407455
如需转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://liuqunying.blog.51cto.com/3984207/1407455