zookeeper本地模式

HADOOPHA场景下，即使Active节点发生故障，系统也不会自动触发从Active到Standby的故障转移。
需要进行手动的故障转移。 手动故障转移显然不是我们所需要的解决方案。 为了实现自动故障转移，
需要引入两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程。

Apache ZooKeeper是一种高可用性服务，用于维护少量协调数据，通知客户端该数据的更改以及监视客户端
是否存在故障。自动故障转移的实现依赖于ZooKeeper来实现以下功能：

1. 故障检测:集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。

2. Active NameNode选举ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。
   如果当前Active节点崩溃，则另一个节点可能从ZooKeeper获得特殊的排他锁以表明它成为下一个Active节点。
   zookeeper 以树的形式管理节点
   ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。
   每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

   1）健康监测：ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复
   健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非
   健康的。
   2）ZooKeeper会话管理：当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。
   如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，
   如果会话终止，锁节点将自动删除。
   3）基于ZooKeeper的选举(word文档)：如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，
   它将为自己获取该锁。如果成功，则它已经赢得了选举，并通过RPC将它的本地NameNode的状态置为active。
   必要时对先前的Active进行隔离（Fence），然后本地NameNode转换为活动状态。
   注意：
   1）DN同时向active和standby发送心跳和块报告
   2）ACTIVE NN将操作记录写到自己的edit log ，同时将edit log写入JN集群。每个JN都会写。
   3）STANDBY NN:?同时接收JN集群的日志（随机选个写入成功的JN节点读），重演edits log操作，使得自己的元数据和active nn节点保持一致。
   4）在激活新的Active NN之前，会对旧的Active NN进行隔离操作防止脑裂。（kill掉）

安装zookeeper:单机模式

a.下载zookeeper3.4.6.tar.gz 通过挂载盘上传
b.解压至【/home/crx/soft】
进入soft文件夹下解压
[crx@master soft]$ tar -zxvf zookeeper-3.4.6.tar.gz
c.创建软连接： > l n − s z o o k e e p e r 3.4.6 / z o o k e e p