ZooKeeper

一 概述

是Apache提供的开源的，用于进行分布式架构的管理的框架。

Zookeeper是根据Google关于Chubby Lock的论文来实现的。

二 分布式带来的问题

1.在分布式条件下，为了确定请求访问的对应的主机，那么引入管理节点。

2.如果管理节只存在一个，存在单点故障，那么需要引入管理集群。

3.在管理集群中，需要选择一个主节点，需要选举算法。

4.当节点宕机，那么需要从节点来立即切换为主节点。

5.主从节点之间要进行时时备份。

三 安装

1.单机：只在一个节点上安装，大部分框架的单机模式只能启动一部分功能。

2.伪分布式：在一个节点上安装，利用不同的端口来模拟集群环境。从而启动框架中所有功能。

3.完全分布式：利用集群安装，能够启动框架中所有的服务。

1.关闭防火墙
service iptables stop
chkconfig iptables off
2.安装JDK
3.下载Zookeeper安装包
    wget http://bj-yzjd.ufile.cn-north-02.ucloud.cn/zookeeper-3.4.8.tar.gz
4.解压
tar -xf 包
5.修改配置文件。

特点

1.Zookeeper本身是一个树状结构。Znode树。

2.根节点是"/"。

3.每一个子节点称之为一个Znode节点。

4.在每一个子节点都必须存储数据，这个数据往往是对这个节点的描述。

5.所有节点的路径都必须从根节点开始计算。

6.任意一个持久节点下都可以挂载子节点。

7.Znode树维护在内存以及磁盘中-在磁盘中存储位置由dataDir决定

8.维系在内存中的目的：快速查询

维系在磁盘中的目的：崩溃恢复

9.Zookeeper理论上可以作为缓存服务器使用，但是实际开发中几乎不这么做。Zookeeper本身是做分布式架构的管理和协调的。如果存储大量数据占用大量内存，就会导致管理和协调所能使用的资源少

10.Zookeeper会对每一次的写操作（creat/set/delete/rmr）分配一个全局递增的编号。这个编号称之为事务id-Zxid

命令

ls /	查看根节点的子节点
create /log 'this is a log servers'	在根节点创建一个子节点log,数据是this is a log servers（创建临时节点 create -e node ‘’ ）
create /log/log01 'log 01'	在log下创建log01子节点
delete /vedio	删除根节点下的video节点（要求节点没有子节点）
rmr /log	递归删除log节点
set /log 'log'	更新log节点数据
get /log	获取log节点数据以及节点信息

 

节点信息

cZxid	创建事务
ctime	创建时间
mZxid	修改事务id
mtime	修改时间
pZxid	子节点的事务变化id
cversion	子节点变化次数
dataVersion	当前节点数据的更新次数（set）
aclVersion	当前节点的权限变化次数
ephemeralOwner	标记当前节点是否是一个临时节点，持久节点0x0,临时节点0x?????(是当前会话session id)
dataLength	数据长度（u8编码）
numChildren	子节点个数

 

节点类型

	持久节点	临时节点
顺序节点	Persistent_Sequential -s	ephemeral_Sequential -e -s
非顺序节点		-e

选举机制

概述

1.第一个阶段：数据恢复阶段。

每一个主机在启动之后，都会先查找当前主机中最大事务id。

2.第二阶段：选举阶段。

刚开始的时候，每一个节点都会选举自己当leader,并且将自己的选举信息发给其他节点。和其他节点进行比较。经过多轮比较之后，会选出一个节点成为leader。

选举信息

a.最大事务id

b.选举编号-myid

c.逻辑时钟值-用于控制所有的节点处在同一轮选举上。

比较过程

a.先比较两个节点之间的最大事务id,谁的最大事务id大谁就胜出

b.如果事务id一致，则比较myid.谁的myid大谁就胜出。

c.如果一个节点赢过一半及以上的节点。那么这个节点就会成为leader.-选举的过半性。

如果leader产生宕机，那么剩余的Zookeeper节点会自动选举出一个新的leader，因此在Zookeeper中不存在单点故障。

如果在集群中因为分裂而导致出现多个leader的现象称之为脑裂。

在Zookeeper中，如果存活的节点数量不足整个集群中节点的数量的一半。那么这个时候Zookeeper集群不再选举也不对外提供服务-因此集群中的节点个数一般也是个奇数。

Zookeeper会对每一次的leader分配一个全局的递增编号-epochid。如果集群中出现了多个leader。那么Zookeeper就会kill掉epochid相对较小的leader。

节点状态变化

looking/voting：选举状态

follower：追随者

leader：领导者

observer：观察者

如果整个集群中已经存在leader，那么新添加的节点的事务id无论是多少。都只能成为follower。

配置参数详解(主要是%ZOOKEEPER_HOME%/conf/zoo.cfg文件)

 

参数名	说明
clientPort	客户端连接server的端口，即对外服务端口，一般设置为2181吧。
dataDir	存储快照文件snapshot的目录。默认情况下，事务日志也会存储在这里。建议同时配置参数dataLogDir, 事务日志的写性能直接影响zk性能。
tickTime	ZK中的一个时间单元。ZK中所有时间都是以这个时间单元为基础，进行整数倍配置的。例如，session的最小超时时间是2*tickTime。
dataLogDir	事务日志输出目录。尽量给事务日志的输出配置单独的磁盘或是挂载点，这将极大的提升ZK性能。   （No Java system property）
globalOutstandingLimit	最大请求堆积数。默认是1000。ZK运行的时候， 尽管server已经没有空闲来处理更多的客户端请求了，但是还是允许客户端将请求提交到服务器上来，以提高吞吐性能。当然，为了防止Server内存溢出，这个请求堆积数还是需要限制下的。   (Java system property:zookeeper.globalOutstandingLimit. )
preAllocSize	预先开辟磁盘空间，用于后续写入事务日志。默认是64M，每个事务日志大小就是64M。如果ZK的快照频率较大的话，建议适当减小这个参数。(Java system property:zookeeper.preAllocSize )
snapCount	每进行snapCount次事务日志输出后，触发一次快照(snapshot), 此时，ZK会生成一个snapshot.*文件，同时创建一个新的事务日志文件log.*。默认是100000.（真正的代码实现中，会进行一定的随机数处理，以避免所有服务器在同一时间进行快照而影响性能）(Java system property:zookeeper.snapCount )
traceFile	用于记录所有请求的log，一般调试过程中可以使用，但是生产环境不建议使用，会严重影响性能。(Java system property:? requestTraceFile )
maxClientCnxns	单个客户端与单台服务器之间的连接数的限制，是ip级别的，默认是60，如果设置为0，那么表明不作任何限制。请注意这个限制的使用范围，仅仅是单台客户端机器与单台ZK服务器之间的连接数限制，不是针对指定客户端IP，也不是ZK集群的连接数限制，也不是单台ZK对所有客户端的连接数限制。指定客户端IP的限制策略，这里有一个patch，可以尝试一下：http://rdc.taobao.com/team/jm/archives/1334（No Java system property）
clientPortAddress	对于多网卡的机器，可以为每个IP指定不同的监听端口。默认情况是所有IP都监听 clientPort 指定的端口。  New in 3.3.0
minSessionTimeoutmaxSessionTimeout	Session超时时间限制，如果客户端设置的超时时间不在这个范围，那么会被强制设置为最大或最小时间。默认的Session超时时间是在2 *  tickTime ~ 20 * tickTime 这个范围 New in 3.3.0
fsync.warningthresholdms	事务日志输出时，如果调用fsync方法超过指定的超时时间，那么会在日志中输出警告信息。默认是1000ms。(Java system property:  fsync.warningthresholdms )New in 3.3.4
autopurge.purgeInterval	在上文中已经提到，3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能。(No Java system property)  New in 3.4.0
autopurge.snapRetainCount	这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。(No Java system property)  New in 3.4.0
electionAlg	在之前的版本中， 这个参数配置是允许我们选择leader选举算法，但是由于在以后的版本中，只会留下一种“TCP-based version of fast leader election”算法，所以这个参数目前看来没有用了，这里也不详细展开说了。(No Java system property)
initLimit	Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。Leader允许F在 initLimit 时间内完成这个工作。通常情况下，我们不用太在意这个参数的设置。如果ZK集群的数据量确实很大了，F在启动的时候，从Leader上同步数据的时间也会相应变长，因此在这种情况下，有必要适当调大这个参数了。(No Java system property)
syncLimit	在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。如果L发出心跳包在syncLimit之后，还没有从F那里收到响应，那么就认为这个F已经不在线了。注意：不要把这个参数设置得过大，否则可能会掩盖一些问题。(No Java system property)
leaderServes	默认情况下，Leader是会接受客户端连接，并提供正常的读写服务。但是，如果你想让Leader专注于集群中机器的协调，那么可以将这个参数设置为no，这样一来，会大大提高写操作的性能。(Java system property: zookeeper. leaderServes )。
server.x=[hostname]:nnnnn[:nnnnn]	这里的x是一个数字，与myid文件中的id是一致的。右边可以配置两个端口，第一个端口用于F和L之间的数据同步和其它通信，第二个端口用于Leader选举过程中投票通信。   (No Java system property)
group.x=nnnnn[:nnnnn]weight.x=nnnnn	对机器分组和权重设置，可以  参见这里(No Java system property)
cnxTimeout	Leader选举过程中，打开一次连接的超时时间，默认是5s。(Java system property: zookeeper.  cnxTimeout )
zookeeper.DigestAuthenticationProvider .superDigest	ZK权限设置相关，具体参见  《  使用super  身份对有权限的节点进行操作 》  和  《 ZooKeeper   权限控制 》
skipACL	对所有客户端请求都不作ACL检查。如果之前节点上设置有权限限制，一旦服务器上打开这个开头，那么也将失效。(Java system property:  zookeeper.skipACL )
forceSync	这个参数确定了是否需要在事务日志提交的时候调用 FileChannel .force来保证数据完全同步到磁盘。(Java system property: zookeeper.forceSync )
jute.maxbuffer	每个节点最大数据量，是默认是1M。这个限制必须在server和client端都进行设置才会生效。(Java system property: jute.maxbuffer )