科技猎ZooKeeper原理概述以及安装讲解
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。 ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper包含一个简单的原语集， 提供Java和C的接口。 ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。
原理
ZooKeeper是以Fast Paxos算法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader，只有leader才能提交proposer，具体算法可见Fast Paxos。因此，要想弄懂ZooKeeper首先得对Fast Paxos有所了解。 ZooKeeper的基本运转流程： 1、选举Leader。 2、同步数据。 3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。 4、Leader要具有最高的zxid。 5、集群中大多数的机器得到响应并follow选出的Leader。
特点
在Zookeeper中，znode是一个跟Unix文件系统路径相似的节点，可以往这个节点存储或获取数据。如果在创建znode时Flag设置为EPHEMERAL，那么当创建这个znode的节点和Zookeeper失去连接后，这个znode将不再存在在Zookeeper里，Zookeeper使用Watcher察觉事件信息。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，可以调用相应的行为来处理数据。Zookeeper的Wiki页面展示了如何使用Zookeeper来处理事件通知，队列，优先队列，锁，共享锁，可撤销的共享锁，两阶段提交。那么Zookeeper能作什么事情呢，简单的例子：假设我们有20个搜索引擎的服务器(每个负责总索引中的一部分的搜索任务)和一个总服务器(负责向这20个搜索引擎的服务器发出搜索请求并合并结果集)，一个备用的总服务器(负责当总服务器宕机时替换总服务器)，一个web的cgi(向总服务器发出搜索请求)。搜索引擎的服务器中的15个服务器提供搜索服务，5个服务器正在生成索引。这20个搜索引擎的服务器经常要让正在提供搜索服务的服务器停止提供服务开始生成索引，或生成索引的服务器已经把索引生成完成可以提供搜索服务了。使用Zookeeper可以保证总服务器自动感知有多少提供搜索引擎的服务器并向这些服务器发出搜索请求，当总服务器宕机时自动启用备用的总服务器。
部署
我需要运行几个ZooKeeper? 你运行一个zookeeper也是可以的，但是在生产环境中，你最好部署3，5，7个节点。部署的越多，可靠性就越高，当然最好是部署奇数个，偶数个不是不可以的，但是zookeeper集群是以宕机个数过半才会让整个集群宕机的，所以奇数个集群更佳。你需要给每个zookeeper 1G左右的内存，如果可能的话，最好有独立的磁盘。 (独立磁盘可以确保zookeeper是高性能的。).如果你的集群负载很重，不要把Zookeeper和RegionServer运行在同一台机器上面。就像DataNodes 和 TaskTrackers一样。
客户端
注：以下代码依赖于PHP扩展libzookeeper 。
连接集群：
$zc = new ZookeeperClient();
$zc->connect('192.168.0.2:2181, 192.168.0.3:2181');
?>
创建节点：
$zc = new ZookeeperClient();
$zc->connect('localhost:2181');
$zc->create('/new_node', 'node_value');
?>
删除节点：
$zc = new ZookeeperClient();
$zc->connect('localhost:2181');
$zc->delete('/existing_node');
?>
获取节点值：
$zc = new ZookeeperClient();
$zc->connect('localhost:2181');
var_dump($zc->get('/existing_node'));
?>
获取子节点：
$zc = new ZookeeperClient();
$zc->connect('localhost:2181');
$childNodes = $zc->getChildren('/parent_node');
foreach ($childNodes as $nodeName) {
var_dump($nodeName);
}
?>
其他
HBase和ZooKeeper HBase内置有ZooKeeper，也可以使用外部ZooKeeper。让HBase使用一个已有的不被HBase托管的Zookeep集群，需要设置 conf/hbase env sh文件中的HBASE_MANAGES_ZK 属性为 false ... # Tell HBase whether it should manage it's own instance of Zookeeper or not. export HBASE_MANAGES_ZK=false 接下来，指明Zookeeper的host和端口。可以在 hbase-site.xml中设置, 也可以在HBase的CLASSPATH下面加一个zoo.cfg配置文件。 HBase 会优先加载 zoo.cfg 里面的配置，把hbase-site.xml里面的覆盖掉. 当HBase托管ZooKeeper的时候，Zookeeper集群的启动是HBase启动脚本的一部分。但你需要自己去运行。你可以这样做 ${HBASE_HOME}/bin/hbase-daemons sh {start,stop} zookeeper 你可以用这条命令启动ZooKeeper而不启动HBase. HBASE_MANAGES_ZK 的值是 false， 如果你想在HBase重启的时候不重启ZooKeeper,你可以这样做对于独立Zoopkeeper的问题，你可以在 Zookeeper启动得到帮助.
ZooKeeper 开放源码的分布式应用程序协调服务
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。本文简单分析zookeeper的工作原理，对于如何使用zookeeper不是本文讨论的重点。
1 Zookeeper的基本概念
1.1 角色
Zookeeper中的角色主要有以下三类，如下表所示：
系统模型如图所示：
1.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前面。
2 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与之同步
2.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会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图如下所示：
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程图如下所示：
2.2 同步流程
选完leader以后，zk就进入状态同步过程。
1. leader等待server连接；
2 .Follower连接leader，将最大的zxid发送给leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知follower 已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。
流程图如下所示：
2.3 工作流程
2.3.1 Leader工作流程
Leader主要有三个功能：
1 .恢复数据；
2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。
Leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。
2.3.2 Follower工作流程
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的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。
对于observer的流程不再叙述，observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。
主流应用场景：
Zookeeper 的主流应用场景实现思路（除去官方示例） (1) 配置管理 集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。 Zookeeper 很容易实现这种集中式的配置管理，比如将 APP1 的所有配置配置到 /APP1 znode 下， APP1 所有机器一启动就对 /APP1 这个节点进行监控 (zk.exist( "/APP1" ,true)), 并且实现回调方法 Watcher ，那么在 zookeeper 上 /APP1 znode 节点下数据发生变化的时候，每个机器都会收到通知， Watcher 方法将会被执行，那么应用再取下数据即可 (zk.getData( "/APP1",false,null )); 以上这个例子只是简单的粗颗粒度配置监控，细颗粒度的数据可以进行分层级监控，这一切都是可以设计和控制的。
(2) 集群管理 应用集群中，我们常常需要让每一个机器知道集群中（或依赖的其他某一个集群）哪些机器是活着的，并且在集群机器因为宕机，网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。 Zookeeper 同样很容易实现这个功能，比如我在 zookeeper 服务器端有一个 znode 叫 /APP1SERVERS, 那么集群中每一个机器启动的时候都去这个节点下创建一个 EPHEMERAL 类型的节点，比如 server1 创建 /APP1SERVERS/SERVER1( 可以使用 ip, 保证不重复 ) ， server2 创建 /APP1SERVERS/SERVER2 ，然后 SERVER1 和 SERVER2 都 watch /APP1SERVERS 这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行 watch 的客户端。因为 EPHEMERAL 类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者 session 过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对 /APP1SERVERS 进行 watch 的客户端都会收到通知，然后取得最新列表即可。 另外有一个应用场景就是集群选 master, 一旦 master 挂掉能够马上能从 slave 中选出一个 master, 实现步骤和前者一样，只是机器在启动的时候在 APP1SERVERS 创建的节点类型变为 EPHEMERAL_SEQUENTIAL 类型，这样每个节点会自动被编号 我们默认规定编号最小的为 master, 所以当我们对 /APP1SERVERS 节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为 master ，那么 master 就被选出，而这个 master 宕机的时候，相应的 znode 会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为 master ，这样就做到动态 master 选举。
Zookeeper 监视（Watches） 简介
Zookeeper C API 的声明和描述在 include/zookeeper.h 中可以找到，另外大部分的 Zookeeper C API 常量、结构体声明也在 zookeeper.h 中，如果如果你在使用 C API 是遇到不明白的地方，最好看看 zookeeper.h，或者自己使用 doxygen 生成 Zookeeper C API 的帮助文档。
Zookeeper 中最有特色且最不容易理解的是监视(Watches)。Zookeeper 所有的读操作—— getData() , getChildren() , 和 exists() 都 可以设置监视(watch)，监视事件可以理解为一次性的触发器， 官方定义如下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。对此需要作出如下理解：
（一次性触发）One-time trigger
当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。
（发送至客户端）Sent to the client
Zookeeper 客户端和服务端是通过 socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但 是不同的客户端所看到的一切具有一致的顺序。
（被 设置 w atch 的数据）The data for which the watch was set
这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表：数据监视和子节点监视(data watches and child watches) getData() and exists() 设置数据监视，getChildren() 设置子节点监视。 或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。因此， setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。
Zookeeper 中的监视是轻量级的，因此容易设置、维护和分发。当客户端与 Zookeeper 服务器端失去联系时，客户端并不会收到监视事件的通知，只有当客户端重新连接后，若在必要的情况下，以前注册的监视会重新被注册并触发，对于开发人员来说 这通常是透明的。只有一种情况会导致监视事件的丢失，即：通过 exists() 设置了某个 znode 节点的监视，但是如果某个客户端在此 znode 节点被创建和删除的时间间隔内与 zookeeper 服务器失去了联系，该客户端即使稍后重新连接 zookeeper服务器后也得不到事件通知。
Zookeeper C API 常量与部分结构(struct)介绍
与 ACL 相关的结构与常量：
struct Id 结构为：
struct Id { char * scheme; char * id; };
struct ACL 结构为：
struct ACL { int32_t perms; struct Id id; };
struct ACL_vector 结构为：
struct ACL_vector { int32_t count; struct ACL *data; };
与 znode 访问权限有关的常量
const int ZOO_PERM_READ; //允许客户端读取 znode 节点的值以及子节点列表。
const int ZOO_PERM_WRITE;// 允许客户端设置 znode 节点的值。
const int ZOO_PERM_CREATE; //允许客户端在该 znode 节点下创建子节点。
const int ZOO_PERM_DELETE;//允许客户端删除子节点。
const int ZOO_PERM_ADMIN; //允许客户端执行 set_acl()。
const int ZOO_PERM_ALL;//允许客户端执行所有操作，等价与上述所有标志的或(OR) 。
与 ACL IDs 相关的常量
struct Id ZOO_ANYONE_ID_UNSAFE; //(‘world’,’anyone’)
struct Id ZOO_AUTH_IDS;// (‘auth’,’’)
三种标准的 ACL
struct ACL_vector ZOO_OPEN_ACL_UNSAFE; //(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)
struct ACL_vector ZOO_READ_ACL_UNSAFE;// (ZOO_PERM_READ, ZOO_ANYONE_ID_UNSAFE)
struct ACL_vector ZOO_CREATOR_ALL_ACL; //(ZOO_PERM_ALL,ZOO_AUTH_IDS)
与 Interest 相关的常量： ZOOKEEPER_WRITE , ZOOKEEPER_READ
这两个常量用于标识感兴趣的事件并通知 zookeeper 发生了哪些事件。Interest 常量可以进行组合或（OR）来标识多种兴趣(multiple interests: write, read)，这两个常量一般用于 zookeeper_interest() 和 zookeeper_process()两个函数中。
与节点创建相关的常量： ZOO_EPHEMERAL , ZOO_SEQUENCE
zoo_create 函数标志， ZOO_EPHEMERAL 用来标识创建临时节点， ZOO_SEQUENCE 用来标识节点命名具有递增的后缀序号(一般是节点名称后填充 10 位字符的序号，如 /xyz0000000000, /xyz0000000001, /xyz0000000002, ...)，同样地， ZOO_EPHEMERAL , ZOO_SEQUENCE 可以组合。
与连接状态 Stat 相关的常量
以下常量均与 Zookeeper 连接状态有关，他们通常用作监视器回调函数的参数。
| ZOOAPI const int | ZOO_EXPIRED_SESSION_STATE |
| ZOOAPI const int | ZOO_AUTH_FAILED_STATE |
| ZOOAPI const int | ZOO_CONNECTING_STATE |
| ZOOAPI const int | ZOO_ASSOCIATING_STATE |
|
ZOOAPI const int |
ZOO_CONNECTED_STATE |
与监视类型(Watch Types)相关的常量
以下常量标识监视事件的类型，他们通常用作监视器回调函数的第一个参数。
-
ZOO_DELETED_EVENT; // 节点被删除， 通过 zoo_exists() 和 zoo_get() 设置监视。
-
ZOO_CHANGED_EVENT; // 节点发生变化，通过 zoo_exists() 和 zoo_get() 设置监视。
-
ZOO_CHILD_EVENT; // 子节点事件，通过zoo_get_children() 和 zoo_get_children2()设置监视。
Zookeeper C API 错误码介绍 ZOO_ERRORS
| ZOK |
正常返回 |
| ZSYSTEMERROR |
系统或服务器端错误(System and server-side errors)，服务器不会抛出该错误，该错误也只是用来标识错误范围的，即大于该错误值，且小于 ZAPIERROR 都是系统错误。 |
| ZRUNTIMEINCONSISTENCY |
运行时非一致性错误。 |
| ZDATAINCONSISTENCY |
数据非一致性错误。 |
| ZCONNECTIONLOSS |
Zookeeper 客户端与服务器端失去连接 |
| ZMARSHALLINGERROR |
在 marshalling 和 unmarshalling 数据时出现错误(Error while marshalling or unmarshalling data) |
| ZUNIMPLEMENTED |
该操作未实现(Operation is unimplemented) |
| ZOPERATIONTIMEOUT |
该操作超时(Operation timeout) |
| ZBADARGUMENTS |
非法参数错误(Invalid arguments) |
| ZINVALIDSTATE |
非法句柄状态(Invliad zhandle state) |
| ZAPIERROR |
API 错误(API errors)， 服务器不会抛出该错误， 该错误也只是用来标识错误范围的，错误值大于该值的标识 API 错误，而小于该值的标识 ZSYSTEMERROR。 |
| ZNONODE |
节点不存在(Node does not exist) |
| ZNOAUTH |
没有经过授权(Not authenticated) |
| ZBADVERSION |
版本冲突(Version conflict) |
| ZNOCHILDRENFOREPHEMERALS |
临时节点不能拥有子节点(Ephemeral nodes may not have children) |
| ZNODEEXISTS |
节点已经存在(The node already exists) |
| ZNOTEMPTY |
该节点具有自身的子节点(The node has children) |
| ZSESSIONEXPIRED |
会话过期(The session has been expired by the server) |
| ZINVALIDCALLBACK |
非法的回调函数(Invalid callback specified) |
| ZINVALIDACL |
非法的ACL(Invalid ACL specified) |
| ZAUTHFAILED |
客户端授权失败(Client authentication failed) |
| ZCLOSING |
Zookeeper 连接关闭(ZooKeeper is closing) |
| ZNOTHING |
并非错误，客户端不需要处理服务器的响应(not error, no server responses to process) |
| ZSESSIONMOVED |
会话转移至其他服务器，所以操作被忽略(session moved to another server, so operation is ignored) |
Watch事件类型：
ZOO_CREATED_EVENT：节点创建事件，需要watch一个不存在的节点，当节点被创建时触发，此watch通过zoo_exists()设置 ZOO_DELETED_EVENT：节点删除事件，此watch通过zoo_exists()或zoo_get()设置 ZOO_CHANGED_EVENT：节点数据改变事件，此watch通过zoo_exists()或zoo_get()设置 ZOO_CHILD_EVENT：子节点列表改变事件，此watch通过zoo_get_children()或zoo_get_children2()设置 ZOO_SESSION_EVENT：会话失效事件，客户端与服务端断开或重连时触发 ZOO_NOTWATCHING_EVENT：watch移除事件，服务端出于某些原因不再为客户端watch节点时触发
zookeeper解决了哪些问题？
回答一：
Backup检测Master存活性传统的就是定期发包，一旦一定时间段内没有收到响应就判定Master Down了，于是Backup就启动，如果Master其实是没有down，Backup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢？Backup也启动了，这时候集群里就有了两个Master，很有可能部分workers汇报给Master，另一部分workers汇报给后来启动的Backup，这下子服务就全乱了。 Backup是定期同步Master中的meta信息，所以总是滞后的，一旦Master挂了，Backup的信息必然是老的，很有可能会影响集群运行状态。
回答二：
分布式系统的运行是很复杂的，因为涉及到了网络通信还有节点失效等不可控的情况。下面介绍在最传统的master-workers模型，主要可以会遇到什么问题，传统方法是怎么解决以及怎么用zookeeper解决。
Master节点管理集群当中最重要的是Master，所以一般都会设置一台Master的Backup。
Backup会定期向Master获取Meta信息并且检测Master的存活性，一旦Master挂了，Backup立马启动，接替Master的工作自己成为Master，分布式的情况多种多样，因为涉及到了网络通信的抖动，针对下面的情况:
Backup检测Master存活性传统的就是定期发包，一旦一定时间段内没有收到响应就判定Master Down了，于是Backup就启动，如果Master其实是没有down，Backup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢？Backup也启动了，这时候集群里就有了两个Master，很有可能部分workers汇报给Master，另一部分workers汇报给后来启动的Backup，这下子服务就全乱了。 Backup是定期同步Master中的meta信息，所以总是滞后的，一旦Master挂了，Backup的信息必然是老的，很有可能会影响集群运行状态。
解决问题:
Master节点高可用，并且保证唯一。 Meta信息的及时同步
zookeeper Master选举
zookeeper会分配给注册到它上面的客户端一个编号，并且zk自己会保证这个编号的唯一性和递增性，N多机器中只需选出编号最小的Client作为Master就行，并且保证这些机器的都维护一个一样的meta信息视图，一旦Master挂了，那么这N机器中编号最小的胜任Master，Meta信息是一致的。
配置文件管理
集群中配置文件的更新和同步是很频繁的，传统的配置文件分发都是需要把配置文件数据分发到每台worker上，然后进行worker的reload，这种方式是最笨的方式，结构很难维护，因为如果集群当中有可能很多种应用的配置文件要同步，而且效率很低，集群规模一大负载很高。还有一种就是每次更新把配置文件单独保存到一个数据库里面，然后worker端定期pull数据，这种方式就是数据及时性得不到同步。
解决问题:
统一配置文件分发并且及时让worker生效
zookeeper发布与订阅模型发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。
分布式锁
在一台机器上要多个进程或者多个线程操作同一资源比较简单，因为可以有大量的状态信息或者日志信息提供保证，比如两个A和B进程同时写一个文件，加锁就可以实现。但是分布式系统怎么办？需要一个三方的分配锁的机制，几百台worker都对同一个网络中的文件写操作，怎么协同？还有怎么保证高效的运行？解决问题:
高效分布式的分布式锁
zookeeper分布式锁
分布式锁主要得益于ZooKeeper为我们保证了数据的强一致性，zookeeper的znode节点创建的唯一性和递增性能保证所有来抢锁的worker的原子性。
集群worker管理
集群中的worker挂了是很可能的，一旦workerA挂了，如果存在其余的workers互相之间需要通信，那么workers必须尽快更新自己的hosts列表，把挂了的worker剔除，从而不在和它通信，而Master要做的是把挂了worker上的作业调度到其他的worker上。同样的，这台worker重新恢复正常了，要通知其他的workers更新hosts列表。传统的作法都是有专门的监控系统，通过不断去发心跳包(比如ping)来发现worker是否alive，缺陷就是及时性问题，不能应用于在线率要求较高的场景解决问题:
集群worker监控
zookeeper监控集群
利用zookeeper建立znode的强一致性，可以用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。
问题：为什么要使用ZooKeeper
回答：
记得在大约在2006年的时候Google出了Chubby来解决分布一致性的问题(distributed consensus problem)，所有集群中的服务器通过Chubby最终选出一个Master Server ，最后这个Master Server来协调工作。简单来说其原理就是：在一个分布式系统中，有一组服务器在运行同样的程序，它们需要确定一个Value，以那个服务器提供的信息为主/为准，当这个服务器经过n/2+1的方式被选出来后，所有的机器上的Process都会被通知到这个服务器就是主服务器 Master服务器，大家以他提供的信息为准。很想知道Google Chubby中的奥妙，可惜人家Google不开源，自家用。
但是在2009年3年以后沉默已久的Yahoo在Apache上推出了类似的产品ZooKeeper，并且在Google原有Chubby的设计思想上做了一些改进，因为ZooKeeper并不是完全遵循Paxos协议，而是基于自身设计并优化的一个2 phase commit的协议，如图所示：
ZooKeeper跟Chubby一样用来存放一些相互协作的信息(Coordination)，这些信息比较小一般不会超过1M，在zookeeper中是以一种hierarchical tree的形式来存放，这些具体的Key/Value信息就store在tree node中。当有事件导致node数据，例如：变更，增加，删除时，Zookeeper就会调用 triggerWatch方法，判断当前的path来是否有对应的监听者(watcher),如果有watcher，会触发其process方法，执行process方法中的业务逻辑
Hadoop+HBase+ZooKeeper三者关系与安装配置
这里有几个主要关系： 1.经过Map、Reduce运算后产生的结果看上去是被写入到HBase了，但是其实HBase中HLog和StoreFile中的文件在进行flush to disk操作时，这两个文件存储到了HDFS的DataNode中，HDFS才是永久存储。 2.ZooKeeper跟Hadoop Core、HBase有什么关系呢？ZooKeeper都提供了哪些服务呢？主要有：管理Hadoop集群中的NameNode，HBase中HBaseMaster的选举，Servers之间状态同步等。具体一点，细一点说，单只HBase中ZooKeeper实例负责的工作就有：存储HBase的Schema，实时监控HRegionServer,存储所有Region的寻址入口，当然还有最常见的功能就是保证HBase集群中只有一个Master。
2、搭建完全分布式集群在做hadoop，hbase这方面的工作有一段时间了，经常有刚接触这些东西的身边朋友，向我询问基本环境的搭建问题，于是就想以回忆录的形式把基本配置的步骤整理出来，以便刚接触的朋友做个参考.
HBase集群建立在hadoop集群基础之上，所以在搭建HBase集群之前需要把Hadoop集群搭建起来，并且要考虑二者的兼容性.现在就以四台机器为例，搭建一个简单的集群.
使用的软件版本：hadoop-1.0.3,hbase-0.94.2,zookeeper-3.4.4.
四台机器IP：10.2.11.1,10.2.11.2,10.2.11.3,10.2.11.4.
一.搭建Hadoop集群
1. 安装JDK.在每台机器下建立相同的目录/usr/java.把下载的jdk（1.6及以上版本）复制到/usr/java目录下面，使用命令 tar –zxvf jdk-7u9-linux-i586.tar.gz sudo chmod 777 jdk-1.7.0_09
把jdk的路径加到环境变量中： vim.tiny /etc/profile
在该文件最后一行添加： JAVA_HOME=/usr/java/jdk1.7.0_09
PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:PATH
CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
使修改的操作生效： source /etc/profile
可以使用 java -version
进行验证是否已配置成功.
2.在每台机器上建立相同的用户名 sudo adduser cloud password cloud
输入你要设置的密码.然后在每台机器作配置： sudo gedit /etc/hosts
打开文件后加入如下内容： 10.2.11.1 namenode 10.2.11.2 datanode1 10.2.11.3 datanode2 10.2.11.4 datanode3
3.在/home/cloud/目录下建立一个文件夹project，命令如下： mkdir project
把hadoop-1.0.3.tar.gz，zookeeper-3.4.4.tar.gz，hbase-0.94.2.tar.gz，这些下载的软件包放在此目录下面，以待下一步操作。 4.使用命令 tar –zxvf hadoop-1.0.3.tar.gz
进行解压文件.进入配置目录，开始配置. cd hadoop-1.0.3/conf
5. 使用命令 ： vim.tiny hadoop-env.sh 把java的安装路径加进去: JAVA_HOME=/usr/java/jdk1.7.0_09/
6. vim.tiny core-site.xml ,加入如下配置：
7. vim.tiny hdfs-site.xml,加入如下配置：
8. gedit mapred-site.xml,添加如下内容：
9. gedit master，加入如下配置内容： namenode
10. gedit slaves，加入如下配置内容： datanode1 datanode2 datanode3
11. 配置机器之间无密码登陆.在每台机器下建立相同目录 .ssh ,如 mkdir /home/cloud/.ssh
在namenode节点下，使用命令ssh-keygen –t rsa，然后一直回车（中间不用输入任何其他信息），直到结束，然后使用命令cd .ssh, cp id_rsa.pub authorized.keys
使用远程传输，把authorized.keys分别复制到其他机器的.ssh目录下面,命令如下： scp authorized_keys datanode1:/home/cloud/.ssh scp authorized_keys datanode2:/home/cloud/.ssh
scp authorized_keys datanode3:/home/cloud/.ssh
进入每台机器的.ssh目录下修改authorized_keys的权限，命令如下： chmod 644 authorized_keys
12.把配置好的hadoop分别拷贝到集群中其他机器上，命令如下： scp –r hadoop-1.0.3 datanode1:/home/cloud/project scp –r hadoop-1.0.3 datanode2:/home/cloud/project
scp –r hadoop-1.0.3 datanode3:/home/cloud/project
13.在namenode机器下，进入hadoop的安装目录，对文件系统进行格式化： bin/hadoop namenode –format
14. 启动集群: bin/start-all.sh. 可以使用 bin/hadoop dfsadmin –report
查看文件系统的使用情况。 使用命令 jps
查看节点服务启动情况，正常情况有：jobtracker、namenode、jps、secondnamenode.否则启动异常，重新检查安装步骤。
二．安装zookeeper 1．在namenode机器下，配置zookeeper，先解压安装包，使用命令： tar -zxvf zookeeper-3.4.4.tar.gz
2.进入zookeeper的配置目录，首先把zoo_sample.cfg重命名一下，可以重新复制一遍，使用命令： cp zoo_sample.cfg zoo.cfg
3.gedit zoo.cfg ,添加如下内容：
dataDir=/home/cloud/project/tmp/zookeeper/data server.1 = datanode1:7000:7001 server.2 =datanode2:7000:7001 server.3 =datanode3:7000:7001
4.把zookeeper分别远程拷贝datanode1，datanode2，datenode3,使用如下命令： scp –r zookeeper-3.4.4 datanode1:/home/cloud/project scp –r zookeeper-3.4.4 datanode2:/home/cloud/project scp –r zookeeper-3.4.4 datanode3:/home/cloud/project
5.分别在刚才的datanode节点/home/cloud/project/tmp/zookeeper/data目录下，新建文件myid，然后使用命令 vim.tiny myid
分别在datanode1,datanode2,datanode3的myid中写入对应的server.n中的n,即分别是1,2,3. 6.开启zookeeper服务,在三台datanode机器的zookeeper安装目录下使用命令： bin/zkServer.sh start
三．部署hbase 1．解压缩hbase的软件包，使用命令： tar -zxvf hbase-0.94.2.tar.gz
2．进入hbase的配置目录，在hbase-env.sh文件里面加入java环境变量.即： JAVA_HOME=/usr/java/jdk1.7.0_09/
加入变量： export HBASE_MANAGES_ZK=false
3. 编辑hbase-site.xml ，添加配置文件：
4. 编辑配置目录下面的文件regionservers. 命令： vim.tiny regionservers
加入如下内容： datanode1 datanode2 datandoe3
5. 把Hbase复制到其他机器，命令如下： scp -r hbase-0.94.2 datanode1:/home/cloud/project scp -r hbase-0.94.2 datanode2:/home/cloud/project scp -r hbase-0.94.2 datanode3:/home/cloud/project
6. 开启hbase服务。命令如下： bin/start-hbase.sh
可以使用bin/hbaseshell 进入hbase自带的shell环境，然后使用命令version等，进行查看hbase信息及建立表等操作。
相关阅读
hadoop是什么：分布式系统基础架构
HBase概念解读：Hadoop数据库
本文为数据观精编文章，数据观网址：www.cbdio.com
责任编辑：陈卓阳