Hadoop学习13--zookeeper相关

zookeeper要保证各个server之间同步，实现同步的协议是zab协议。此协议有两种模式：恢复模式（选主）和广播模式（同步）。

服务启动或者leader崩溃时，进入恢复模式。选举成功且大多数server完成了和leader的状态同步后（2n+1台中的n+1台），恢复模式就结束了。

状态同步保证了leader和Server具有相同的系统状态。为了保证事务的顺序一致性，zookeeper采用了递增的事务id号 （zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用 来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递 增计数。

同步流程 选完leader以后，zk就进入状态同步过程。 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消息，根据不同的消息类型，进行不同的处理。 PING 消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议 的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。

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结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

以上内容引用自这篇博客，里面有流程图：

http://www.cnblogs.com/kunpengit/p/4045334.html

一、配置项解释：

zoo.cfg=>

initLimit=10

syncLimit=5

tickTime=2000

dataDir=E:/zookeeper/zookeeper-3.4.5/data

dataLogDir=。。。

clientPort=2181

leaderServes=no

globalOutstandingLimit=1000

server.1=slave1:2887:3887 server.2=slave2:2887:3887 server.3=slave3:2887:3887

解释：

initLimit：集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）。F在启动时，会从Leader同步所有的最新数据，然后确定自己能对外服务的起始状态。L允许在这个时间范围内完成这个工作。如果ZK集群的数据量很大，F在启动的时候，同步的时间就会很长，需要相应调大这个参数。

syncLimit：集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。在集群运行过程中，L负责与所有的机器进行通信，例如通过心跳检测机器是否存货。如果发出的心跳包在这个时间范围内没有收到响应，那么就会弃用这个机器。这个值不宜设置过大。

tickTime:心跳时间，客户端在服务端保留session，最小的session过期时间，是tickTime的2倍。

dataDir:用来存储在内存中的数据库快照。

logDir:

leaderServes：默认情况下，leader机器会接收客户端的读写请求。如果设置为no，该机器将会专注于急群众机器的协调工作。以此来提高写操作的性能。

clientPort:监听客户端连接的端口号。

globalOutstandingLimit：最大请求堆积数。默认是1000。ZK运行的时候， 尽管server已经没有空闲来处理更多的客户端请求了，但是还是允许客户端将请求提交到服务器上来，以提高吞吐性能。当然，为了防止Server内存溢出，这个请求堆积数还是需要限制下的。

server.1中的1对应上面配置的dataDir目录下的myid文件中的值

两个端口：第一个是F和L之间通信（数据同步和其他通信）的端口，第二个是用于leader选举中投票通信。

扩展：

preAllocSize：预先开辟磁盘空间，用于后续写入事务日志。默认是64M，每个事务日志大小就是64M。如果ZK的快照频率较大的话，建议适当减小这个参数。

snapCount：每进行snapCount次事务日志输出后，触发一次快照(snapshot), 此时，ZK会生成一个snapshot.*文件，同时创建一个新的事务日志文件log.*。默认是100000.（真正的代码实现中，会进行一定的随机数处理，以避免所有服务器在同一时间进行快照而影响性能）

traceFile：用于记录所有请求的log，一般调试过程中可以使用，但是生产环境不建议使用，会严重影响性能。

autopurge.purgeInterval：3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能。

autopurge.snapRetainCount：这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。

二、命令：

启动和重启

bin/zkServer.sh start / restart

查看状态

bin/zkServer.sh status

集群中应该只有一台leader，其余是follower 和looking（当前server不知道leader是谁，正在搜寻）

查看节点的详细配置信息：

echo conf | nc slave1 2181

查看节点的当前性能和连接客户端列表：

echo stat | nc slave1 2181

上述命令的简化版本：

echo cons |nc slave1 2181 仅仅列出当前连接到服务器的客户端的信息

列出当前机器环境的详细信息：

echo reqs |nc slave1 2181 

列出watch详细信息：

echo wchs |nc slave1 2181 

通过session列出服务器watch信息

echo wchc |nc slave1 2181 

通过路径列出服务器watch信息

echo wchp |nc slave1 2181 

列出未经处理的会话和临时节点：

echo dump |nc slave1 2181 

列出所有未处理请求：

echo cons |nc slave1 2181 

另一个关掉server的命令：

echo kill | nc salve1 2181 

打开客户端

bin/zkCli.sh -server slave1:2181

　　列出节点：ls / 

　　列出节点以及版本信息（增删节点会更新）、节点数量等内容：ls2 /

　　创建节点： create /testzk  wordwordword   后面的是存入的内容字符串

　　查看：get /testzk   包括内容，以及版本等

　　设置内容字符串：set /testzk sssss 执行后，替换了

　　删除znode delete /testzk 

　   退出客户端： quit

经验之谈：

1、今天遇到一个问题，过程是这样的：

我使用客户端连接到了三台集群机器上，后来从一台机器客户端界面ssh到了另一台上，这样，就相当于我打开了三个客户端界面，其实其中两个是连到了同一台机器，然，我却不知。然后逐台启动zookeeper，启动后习惯性的查看状态：bin/zkServer.sh status 发现一个奇怪的现象，每一台都是follower！我一开始怀疑是集群出错了。但是用jps查看，服务都是正常启动的。中间各种排查、搜索不表，最后发现了事情的原因。

这说明，要求zookeeper集群机器数必须是奇数的。因为选举算法，不能保证偶数台机器，每次都能选出leader（之所以这么说，是因为我有时候在启动集群时，发现当启动了两台的时候，leader已经产生了）。于是忍不住好奇，去研究相关的内容：

 zookeeper集群自身维护了一套数据结构。是一个树形结构。其上的每一个节点，称之为znode。每一个znode默认能存储1MB数据（对于存储状态性质的数据足够）。可以通过zkCli连上集群，操作这些znode。

znode的结构是什么样的呢？

zxid：时间戳。每次修改znode都会生成新的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。

version：对节点每次修改，版本号+1

data：存储的数据。对之修改，会引起以上两者变化（修改数据，是对当前znode影响，对上级的znode则不会影响）

tick：租约协议的具体实现。（比较晦涩，如果当前节点是临时节点，那么在tick时间周期内没收到新的客户端租约，则视为失效）

选举规则：

默认选举规则称为：FastLeaderELection

详情请参考这篇博客：

http://blog.csdn.net/xhh198781/article/details/6619203