http://Hadoop.apache.org/zookeeper/releases.html

http://labs.renren.com/apache-mirror//hadoop/zookeeper/

#Set ZooKeeper Enviroment

export ZOOKEEPER_HOME=/root/hadoop-0.20.2/zookeeper-3.3.1

export PATH=$PATH:$ZOOKEEPER_HOME/bin:$ZOOKEEPER_HOME/conf

tickTime=2000

dataDir=/var/zookeeper

clientPort=2181

# The number of milliseconds of each tick

tickTime=2000

 

# the directory where the snapshot is stored.

dataDir=/root/hadoop-0.20.2/zookeeper-3.3.1/snapshot/data

 

# the port at which the clients will connect

clientPort=2181

tickTime=2000

dataDir=/var/zookeeper/

clientPort=2181

initLimit=5

syncLimit=2

server.1=zoo1:2888:3888

server.2=zoo2:2888:3888

server.3=zoo3:2888:3888

# The number of milliseconds of each tick

tickTime=2000

 

# The number of ticks that the initial

# synchronization phase can take

initLimit=10

 

# The number of ticks that can pass between

# sending a request and getting an acknowledgement

syncLimit=5

 

# the directory where the snapshot is stored.

dataDir=/root/hadoop-0.20.2/zookeeper-3.3.1/snapshot/d1

 

# the port at which the clients will connect

clientPort=2181

 

server.1=IP1:2887:3887

server.2=IP2:2888:3888

server.3=IP3:2889:3889

# The number of milliseconds of each tick

tickTime=2000

 

# The number of ticks that the initial

# synchronization phase can take

initLimit=10

 

# The number of ticks that can pass between

# sending a request and getting an acknowledgement

syncLimit=5

 

# the directory where the snapshot is stored.

dataDir=/root/hadoop-0.20.2/zookeeper-3.3.1/d_1

 

# the port at which the clients will connect

clientPort=2181

 

server.1=localhost:2887:3887

server.2=localhost:2888:3888

server.3=localhost:2889:3889

# The number of milliseconds of each tick

tickTime=2000

 

# The number of ticks that the initial

# synchronization phase can take

initLimit=10

 

# The number of ticks that can pass between

# sending a request and getting an acknowledgement

syncLimit=5

 

# the directory where the snapshot is stored.

dataDir=/root/hadoop-0.20.2/zookeeper-3.3.1/d_2

 

# the port at which the clients will connect

clientPort=2182

 

#the location of the log file

dataLogDir=/root/hadoop-0.20.2/zookeeper-3.3.1/logs

 

server.1=localhost:2887:3887 

server.2=localhost:2888:3888

server.3=localhost:2889:3889

# The number of milliseconds of each tick

tickTime=2000

 

# The number of ticks that the initial

# synchronization phase can take

initLimit=10

 

# The number of ticks that can pass between

# sending a request and getting an acknowledgement

syncLimit=5

 

# the directory where the snapshot is stored.

dataDir=/root/hadoop-0.20.2/zookeeper-3.3.1/d_2

 

# the port at which the clients will connect

clientPort=2183

 

#the location of the log file

dataLogDir=/root/hadoop-0.20.2/zookeeper-3.3.1/logs

 

server.1=localhost:2887:3887 

server.2=localhost:2888:3888

server.3=localhost:2889:3889

#the location of the log file

dataLogDir=/root/hadoop-0.20.2/zookeeper-3.3.1/log/data_log

#set maxClientCnxns

maxClientCnxns=1

#set minSessionTimeout

minSessionTimeout=1000

 

#set maxSessionTImeout

maxSessionTimeout=10000

ZooKeeper系列之五：ZooKeeper的运行

 

我们这里所介绍的是对应 ZooKeeper系列之三：ZooKeeper的安装 模式的运行。

 

1）单机模式

 

用户可以通过下面的命令来启动 ZooKeeper 服务：

这个命令默认情况下执行 ZooKeeper 的 conf 文件夹下的 zoo.cfg 配置文件。当运行成功用户会看到类似如下的提示界面：

从上面可以看出，运行成功后，系统会列出 ZooKeeper 运行的相关环境配置信息。

 

2）集群模式

 

集群模式下需要用户在每台 ZooKeeper 机器上运行第一部分的命令，这里不再赘述。

 

3）集群伪分布模式

 

在集群伪分布模式下，我们只有一台机器，但是要运行三个 ZooKeeper 服务实例。此时，如果再使用上述命令式肯定行不通的。这里，我们通过下面三条命能够令来运行 ZooKeeper系列之三：ZooKeeper的安装 中 我们配置的 ZooKeeper 服务。如下所示：

 

 

在运行完第一条命令之后，读者将会发现一些系统错误提示，如下图 1 所示：

图 1 ：集群伪分布异常提示

产生如上图所示的异常信息是由于 ZooKeeper 服务的每个实例都拥有全局的配置信息，它们在启动的时候需要随时地进行 Leader 选举操作（此部分内容下面将会详细讲述）。此时第一个启动的 Zookeeper 需要和另外两个 ZooKeeper 实例进行通信。但是，另外两个 ZooKeeper 实例还没有启动起来，因此将会产生上述所示的异常信息。

我们直接将其忽略即可，因为当把图示中的“ 2 号”和“ 3 号” ZooKeeper 实例启动起来之后，相应的异常信息就回自然而然地消失。

 

----------------------------

ZooKeeper系列之六：ZooKeeper四字命令

 

    

ZooKeeper 支持某些特定的四字命令字母与其的交互。它们大多是查询命令，用来获取 ZooKeeper 服务的当前状态及相关信息。用户在客户端可以通过 telnet 或 nc 向 ZooKeeper 提交相应的命令。 ZooKeeper 常用四字命令见下表 1 所示：

表 1 ： ZooKeeper 四字命令

ZooKeeper 四字命令	功能描述
conf	输出相关服务配置的详细信息。
cons	列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。
dump	列出未经处理的会话和临时节点。
envi	输出关于服务环境的详细信息（区别于 conf 命令）。
reqs	列出未经处理的请求
ruok	测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应。
stat	输出关于性能和连接的客户端的列表。
wchs	列出服务器 watch 的详细信息。
wchc	通过 session 列出服务器 watch 的详细信息，它的输出是一个与watch 相关的会话的列表。
wchp	通过路径列出服务器 watch 的详细信息。它输出一个与 session相关的路径。

下图 1 是 ZooKeeper 四字命令的简单用例：

图 1 ： ZooKeeper 四字命令用例

ZooKeeper系列之七：ZooKeeper命令行工具

 

当启动 ZooKeeper 服务成功之后，输入下述命令，连接到 ZooKeeper 服务：

连接成功后，系统会输出 ZooKeeper 的相关环境以及配置信息，并在屏幕输出“ Welcome to ZooKeeper”等信息。

输入 help 之后，屏幕会输出可用的 ZooKeeper 命令，如下图 1 所示：

 

 

图 1 ： ZooKeeper 命令

 

 

 

ZooKeeper系列之八：ZooKeeper的简单操作

 

 

 

 

 

1 ）使用 ls 命令来查看当前 ZooKeeper 中所包含的内容：

2 ）创建一个新的 znode ，使用 create /zk myData 。这个命令创建了一个新的 znode 节点“ zk ”以及与它关联的字符串：

3 ）再次使用 ls 命令来查看现在 zookeeper 中所包含的内容：

此时看到， zk 节点已经被创建。

4 ）下面我们运行 get 命令来确认第二步中所创建的 znode 是否包含我们所创建的字符串：

5 ）下面我们通过 set 命令来对 zk 所关联的字符串进行设置：

6 ）下面我们将刚才创建的 znode 删除：

7 ）最后再次使用 ls 命令查看 ZooKeeper 所包含的内容：

经过验证， zk 节点已经被删除。

 

 

 

----------------------------------------------

 

 

ZooKeeper系列之九：ZooKeeper API简介及编程

 

 

1)ZooKeeper API 简介

ZooKeeper API 共包含 5 个包，分别为： org.apache.zookeeper ， org.apache.zookeeper.data ，org.apache.zookeeper.server ， org.apache.zookeeper.server.quorum 和org.apache.zookeeper.server.upgrade 。其中 org.apache.zookeeper 包含 ZooKeeper 类，它我们编程时最常用的类文件。

这个类是 ZooKeeper 客户端库的主要类文件。如果要使用 ZooKeeper 服务，应用程序首先必须创建一个Zookeeper 实例，这时就需要使用此类。一旦客户端和 ZooKeeper 服务建立起连接， ZooKeeper 系统将会分配给此连接回话一个 ID 值，并且客户端将会周期地向服务器发送心跳来维持会话的连接。只要连接有效，客户端就可以调用 ZooKeeper API 来做相应的处理。

它提供了表 1 所示几类主要方法 , ：

  表 1 ： ZooKeeper API 描述

 

2)ZooKeeper API 的使用

这里，笔者通过一个例子来简单介绍，如何使用 ZooKeeper API 编写自己的应用程序，见代码清单 1 ：

代码清单 1 ： ZooKeeper API 的使用

 

此类包含两个主要的 ZooKeeper 函数，分别为 createZKInstance （）和 ZKOperations （）。其中createZKInstance （）函数负责对 ZooKeeper 实例 zk 进行初始化。 ZooKeeper 类有两个构造函数，我们这里使用“ ZooKeeper （ String connectString, ， int sessionTimeout, ， Watcher watcher ）”对其进行初始化。因此，我们需要提供初始化所需的，连接字符串信息，会话超时时间，以及一个 watcher 实例。 17 行到 23 行代码，是程序所构造的一个 watcher 实例，它能够输出所发生的事件。

ZKOperations （）函数是我们所定义的对节点的一系列操作。它包括：创建 ZooKeeper 节点（ 33 行到 34行代码）、查看节点（ 36 行到 37 行代码）、修改节点数据（ 39 行到 40 行代码）、查看修改后节点数据（ 42行到 43 行代码）、删除节点（ 45 行到 46 行代码）、查看节点是否存在（ 48 行到 49 行代码）。另外，需要注意的是：在创建节点的时候，需要提供节点的名称、数据、权限以及节点类型。此外，使用 exists 函数时，如果节点不存在将返回一个 null 值。关于 ZooKeeper API 的更多详细信息，读者可以查看 ZooKeeper 的 API 文档，如下所示：

 

 

--------------------------------------------------

 

 

 

 

ZooKeeper系列之十：ZooKeeper的一致性保证及Leader选举

 

 

 

 

    

     1）一致性保证

 

 

Zookeeper 是一种高性能、可扩展的服务。 Zookeeper 的读写速度非常快，并且读的速度要比写的速度更快。另外，在进行读操作的时候， ZooKeeper 依然能够为旧的数据提供服务。这些都是由于 ZooKeepe 所提供的一致性保证，它具有如下特点：

  顺序一致性

客户端的更新顺序与它们被发送的顺序相一致。

 

原子性

更新操作要么成功要么失败，没有第三种结果。

 

单系统镜像

无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。

 

  可靠性

一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。。这个保证将会产生下面两种结果：

1 ．如果客户端成功地获得了正确的返回代码，那么说明更新已经成果。如果不能够获得返回代码（由于通信错误、超时等等），那么客户端将不知道更新操作是否生效。

2 ．当从故障恢复的时候，任何客户端能够看到的执行成功的更新操作将不会被回滚。

 

  实时性

在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。

给予这些一致性保证， ZooKeeper 更高级功能的设计与实现将会变得非常容易，例如： leader 选举、队列以及可撤销锁等机制的实现。

 

2）Leader选举

 

ZooKeeper 需要在所有的服务（可以理解为服务器）中选举出一个 Leader ，然后让这个 Leader 来负责管理集群。此时，集群中的其它服务器则成为此 Leader 的 Follower 。并且，当 Leader 故障的时候，需要ZooKeeper 能够快速地在 Follower 中选举出下一个 Leader 。这就是 ZooKeeper 的 Leader 机制，下面我们将简单介绍在 ZooKeeper 中， Leader 选举（ Leader Election ）是如何实现的。

此操作实现的核心思想是：首先创建一个 EPHEMERAL 目录节点，例如“ /election ”。然后。每一个ZooKeeper 服务器在此目录下创建一个 SEQUENCE| EPHEMERAL 类型的节点，例如“ /election/n_ ”。在SEQUENCE 标志下， ZooKeeper 将自动地为每一个 ZooKeeper 服务器分配一个比前一个分配的序号要大的序号。此时创建节点的 ZooKeeper 服务器中拥有最小序号编号的服务器将成为 Leader 。

在实际的操作中，还需要保障：当 Leader 服务器发生故障的时候，系统能够快速地选出下一个 ZooKeeper服务器作为 Leader 。一个简单的解决方案是，让所有的 follower 监视 leader 所对应的节点。当 Leader 发生故障时， Leader 所对应的临时节点将会自动地被删除，此操作将会触发所有监视 Leader 的服务器的 watch 。这样这些服务器将会收到 Leader 故障的消息，并进而进行下一次的 Leader 选举操作。但是，这种操作将会导致“从众效应”的发生，尤其当集群中服务器众多并且带宽延迟比较大的时候，此种情况更为明显。

在 Zookeeper 中，为了避免从众效应的发生，它是这样来实现的：每一个 follower 对 follower 集群中对应的比自己节点序号小一号的节点（也就是所有序号比自己小的节点中的序号最大的节点）设置一个 watch 。只有当follower 所设置的 watch 被触发的时候，它才进行 Leader 选举操作，一般情况下它将成为集群中的下一个Leader 。很明显，此 Leader 选举操作的速度是很快的。因为，每一次 Leader 选举几乎只涉及单个 follower 的操作。