Zookeeper和HA的了解

一、Zookeeper的概述
1.1Zookeeper是什么

1. zookeeper是⼀个伪分布式应⽤程序提供的⼀个分布式开源协调服务框架。是Google的Chubby的⼀个开源实现，是Hadoop和Hbase的重要组件。主要⽤于解决分布式集群中应用系统的⼀致性问题。
2. 提供了基于类似Unix系统的目录节点树方式的数据存储。
3. 可用于维护和监控存储数据的状态的变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理
4. 提供了⼀组原语(机器指令)，提供了java和c语⾔的接⼝

1.2 Zookeeper的特点

• 也是⼀个分布式集群，⼀个领导者(leader),多个跟随者(follower).
• 集群中只要有半数以上的节点存活，Zookeeper集群就能正常服务。
• 全局数据⼀致性：每个server保存⼀份相同的数据副本，client⽆论连接到哪个server,数据都是⼀致的。
• 更新请求按顺序进行：来自同⼀个client的更新请求按其发送顺序依次执行
• 数据更新的原子性：一次数据的更新要么成功，要么失败
• 数据的实时性：在⼀定时间范围内，client能读到最新数据。

1.3 Zookeeper的数据模型
Zookeeper的数据模型采用的与Unix文件系统类似的层次化的树形结构。我们可以将其理解为⼀个具有高可用特征的文件系统。这个文件系统中没有文件和目录，而是统⼀使用"节点"(node)的概念，称之为znode。znode既可以作为保存数据的容器(如同文件),也可以作为保存其他znode的容器(如同目录)。所有的znode构成了⼀个层次化的命名空间。

• Zookeeper 被设计用来实现协调服务（这类服务通常使用小数据文件)，而不是用于大容量数据存储，因此⼀个znode能存储的数据被限制在1MB以内，
• 每个znode都可以通过其路径唯⼀标识。

1.4 Zookeeper的应用场景

1. 统⼀配置管理
2. 统⼀集群管理
3. 服务器节点动态上下线感知
4. 软负载均衡等
5. 分布式锁
6. 分布式队列

1.5Zookeeper的安装
后期整理

二、Zookeeper的工作原理

2.1选举制度
2.1.1说明

• 基于节点在半数以上才能正常服务的要求，Zookeeper适合装在奇数台机器。
• Zookeeper没有在配置⽂件中指定leader和follower，而是使用算法(Paxos)在内部通过选举机制来选择⼀个节点为leader，其他节点为follower。
  2.1.2开机启动时的选举过程
  假设有五台服务器组成的 zookeeper 集群，它们的 id 从 1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这⼀点上，都是⼀样的。假设这些服务器依序启动，来看看会发⽣什么。
  1. 服务器1启动
     此时只有它⼀台服务器启动了，它发出去的投票信息没有任何响应，所以它的选举状态⼀直是 LOOKING 状态。
  2. 服务器2启动它与最开始启动的服务器 1 进行通信，互相交换⾃⼰的选举结果，由于两者都没有历史数据，所以 id 值较大的服务器 2 胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例⼦中的半数以上是 3)，所以服务器 1、 2 还是继续保持LOOKING 状态。
  3. 服务器3启动根据前⾯的理论分析，服务器 3 成为服务器 1、 2、 3 中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的 leader。
  4. 服务器4启动根据前⾯的分析，理论上服务器 4 应该是服务器 1、 2、 3、 4 中最大的，但是由于前面已经有半数以上的服务器选举了服务器 3，所以它只能接收当小弟的命了
  5. 服务器5启动
     同 4 ⼀样当小弟

2.2选举制度中的四个概念

• Leader:Zookeeper 集群⼯作的核心。
  事务请求（写操作） 的唯⼀调度和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。对于 create， setData， delete 等有写操作的请求，需要统⼀转发给leader 处理， leader 需要决定编号、执⾏操作，这个过程称为⼀个事务。
• Follower:处理客户端⾮事务(读操作)请求
  转发事务请求给 Leader；参与集群 Leader 选举投票 2n-1台可以做集群投票。此外，针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。
• Observer:观察者角色
  观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理。不会参与任何形式的投票只提供⾮事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的⾮事务处理能力。
• serverid:服务器id
  比如有三台服务器，编号分别为1，2，3。编号越⼤在选择算法中的权重越大
• zxid:数据id
  服务器中存放的最⼤数据ID。值越大说明数据越新，在选举算法中的权重越大
• Epoch:逻辑时钟
  也可以称之为每个服务器参加投票的次数。同⼀轮投票过程中的逻辑次数
  优先级：Epoch > zxid >serverid
• Server状态：选举状态
  • LOOKING：竞选状态
  • FOLLOWING:随从状态，同步leader状态，参与选票
  • OBSERVING:观察状态，同步leader状态，不参与选票
  • LEADER：领导者状态

三、HA的介绍
3.1 HA（high availability）的使用原因

1. 问题所在：

• 计划外的事件，比如：单点故障(SPOF)
• 计划内的事件，比如：namenode上的硬件或软件升级

2. 解决办法：

• 使⽤两个Namenode：
  ⼀个是正在⼯作的namenode，可以称之为Active节点;另外⼀个namenode充当备份节点,称之为Standby节点;当Active节点不能使⽤了，Standby节点会⽴即转为Active状态，来接管集群，使之正常⼯作，这就是现在的HDFS的⾼可⽤性，简称HA。这种状态的切换，对用户来说是透明的。
• 注意：standby节点会执行检查点机制，因此不需要配置secondarynamenode.

3.2两个Namenode的缺点

3.3JournalNode集群的功能介绍
3.3.1每个journalnode节点都存储编辑⽇志
为了使备用节点保持其状态与活动节点同步，两个节点都与⼀组称为“ JournalNodes”（JN）的单独守护程序进行通信。当活动节点执行任何命名空间的修改时，它会持久地将修改记录记录到⼤多数这些JN中。Standby节点会⼀直监视JN，以查看编辑日志的更改。当“备用节点”看到编辑内容更改后，会将其应⽤于自己的命名空间。发生故障转移时，备用节点将确保在将⾃身升级为活动状态之前，已从JounalNodes读取所有编辑内容。这样可确保在发⽣故障转移之前，名称空间状态已完全同步
3.3.2防止脑裂的发生
对于HA群集的正确操作至关重要，⼀次只能有⼀个NameNode处于Active状态。否则，名称空间状态将在两者之间迅速分散，从而有数据丢失或其他不正确结果的风险。

• 为了确保该属性并防止所谓的“裂脑情况”，JournalNode将⼀次仅允许单个NameNode成为作者。在故障转移期间，变为活动状态的NameNode将仅承担写入JournalNodes的角色，这将有效地防止另⼀个NameNode继续处于活动状态，从而使新的Active可以安全地进行故障转移。
• 怎么理解脑裂？
  就是Active节点处于网络震荡状态，假死状态，Standby就转为Active。等网络震荡过后，就有两个Active了，这就是脑裂。

3.3.3journalnode集群正常工作的条件

• ⾄少3个Journalnode节点
• 运行个数建议奇数个(3,5,7等)
• 满足（n+1）/2个以上，才能正常服务。即能容忍（n-1）/2个故障。

3.3.4 datanode同时向两个namenode心跳反馈
为了提供快速的故障转移，备用节点还必须具有集群中块位置的最新信息。为了实现这⼀点，DataNodes被配置了两个NameNodes的位置，并向两者发送块位置信息和心跳信号。

3.3.5journalnode的缺点
在这种模式下，即使活动节点发生故障，系统也不会自动触发从活动NameNode到备用NameNode的故障转移，必须需要人为的操作才行。要是有⼀个能监视Active节点的服务功能就好了。这个时候，我们就可以使⽤zookeeper集群服务，来帮助我们进行自动容灾了。

3.4 HA的⾃动容灾原理(ZKFC原理)
如果想进行HA的自动故障转移，那么需要为HDFS部署两个新组件：ZooKeeperquorum和ZKFailoverController进程（缩写为ZKFC）。

3.4.1Zookeeper quorum
Apache ZooKeeper是⼀项高可用性服务，用于维护少量的协调数据，将数据中的更改通知客户端并监视客户端的故障。HDFS自动故障转移的实现依赖ZooKeeper进行以下操作：

• 故障检测
  群集中的每个NameNode计算机都在ZooKeeper中维护⼀个持久性会话。如果计算机崩溃，则ZooKeeper会话将终⽌，通知另⼀个NameNode应触发故障转移。
• 活动的NameNode选举(HA的第⼀次启动)ZooKeeper提供了⼀种简单的机制来专⻔选举⼀个节点为活动的节点。如果当前活动的NameNode崩溃，则另⼀个节点可能会在ZooKeeper中采取特殊的排他锁，指示它应成为下⼀个活动的NameNode

3.4.2ZKFC的介绍
ZKFailoverController（ZKFC）是⼀个新组件，它是⼀个ZooKeeper客户端，它监视和管理namenode的状态。运行namenode的每台机器都会运行⼀个ZKFC，该ZKFC负责以下内容：

• 运行状况监视ZKFC使⽤运⾏状况检查命令定期ping其本地NameNode。只要NameNode以健康状态及时响应，ZKFC就会认为该节点是健康的。如果节点崩溃，冻结或以其他⽅式进⼊不正常状态，则运⾏状况监视器将其标记为不正常。
• ZooKeeper会话管理当本地NameNode运⾏状况良好时，ZKFC会在ZooKeeper中保持打开的会话。如果本地NameNode处于活动状态，则它还将持有⼀个特殊的“锁定” znode。该锁使⽤ZooKeeper对“临时”节点的⽀持。如果会话到期，则锁定节点将被⾃动删除。
• 基于ZooKeeper的选举如果本地NameNode运⾏状况良好，并且ZKFC看到当前没有其他节点持有锁znode，则它本身将尝试获取该锁。如果成功，则它“赢得了选举”，并负责运⾏故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述的⼿动故障转移：首先，如有必要，将先前的活动节点隔离，然后将本地NameNode转换为活动状态。