文章目录
- 04 文末
01 引言
在前面的教程，我们对HDFS有一个简单的认识以及会使用它的命令了，有兴趣的同学可以参阅：
本文继续讲解概念问题，HDFS是如何保证高可用和容错的?
02 HDFS高可用
2.1 DataNode高可用
2.1.1 DataNode高可用概述
先来看看一张图：
比如DataNode-1宕机了，因为HDFS 是一个分布式文件系统，它会给文件创建副本并把副本分发到集群的节点上，所以会去其他节点读取相同的数据，这样就实现了高可用了。
2.2.2 DataNode高可用原理
原理：集群中的DataNode会向NameNode发送心跳，如果NameNode在规定时间没有接收到心跳，会认定DataNode发生了故障了，加入DataNode出现了故障，NameNode接着会向集群中的未损坏的DataNode发送指令，创建数据并拷贝到另外的DataNode，这样就保持了高可用了。
2.2 NameNode高可用
2.2.1 NameNode高可用概述
在 Hadoop 2.x 之前，一个集群只有一个NameNode，这将面临单点故障问题，所以之后Hadoop 2.0克服了 NameNode 单点故障问题，架构图如下:
即有两个NameNode节点，分别是：
- 活动
Namenode：负责处理集群中所有客户端请求； - 备用
Namenode：备用节点，拥有和活动的 Namenode 一样的元数据。在活动Namenode 失效后，会接管它的工作。
注意：
- 活动和备用
Namenode两者总是同步的：它们存储着一样的元数据，这可以把集群恢复到系统奔溃时的状态。而且基于此还能实现自动故障切换。 - 同一时间，集群只能有一个活动的
Namenode 节点：两个Namenode 会导致数据发生错乱并且无法恢复。我们把这种情况称为“脑裂”现象（即一个集群被分成两个小集群，并且两边都认为自己是唯一活动的集群，Zookeeper社区对这种问题的解决方法叫做fencing，中文翻译为隔离）
2.2.2 NameNode高可用实现原理
NameNode主要通过以下两种方式实现高可用：
- 隔离（
fencing） -
Quorum Journal Manager（QJM）共享存储
2.2.2.1 隔离（fencing）
隔离（Fencing）:是为了防止脑裂，就是保证在任何时候HDFS只有一个Active NN，主要包括三个方面：
- 共享存储fencing：确保只有一个
NN可以写入edits； - 客户端f encing：确保只有一个
NN可以响应客户端的请求。 - DataNode fencing：确保只有一个
NN 可以向DataNode 下发命令，譬如删除块，复制块，等等。
QJM 的 Fencing 方案只能让原来的 Active Namenode 失去对 JN 的写权限，但是原来的 Active Namenode 还是可以响应客户端的请求，对 Datanode 进行读。对客户端和 DataNode 的 fence 是通过配置 dfs.ha.fencing.methods 实现的。
Hadoop 公共库中有两种Fencing实现：
- sshfence：ssh到原Active NN上，使用fuser结束进程（通过tcp端口号定位进程 pid，该方法比 jps 命令更准确）。
- shell：即执行一个用户事先定义的shell命令（脚本）完成隔离。
2.2.2.1 共享存储（QJM）
Qurom Journal Manager（QJM）是一个基于Paxos算法实现的 HDFS元数据共享存储的方案。
QJM 的基本原理：
- 用
2N+1 台JournalNode 存储EditLog - 每次写数据操作有大多数（
>=N+1）返回成功时即认为该次写成功，数据不会丢失。
这个算法所能容忍的是最多有 N台机器挂掉，如果多于N台挂掉，这个算法就失效了。这个原理是基于Paxos 算法的。
03 HDFS容错
3.1 HDFS容错概述
看看下图：
HDFS 是具有很好的容错性的分布式存储系统，它利用复制技术实现数据容错能力，数据会被复制多份并存储在集群的不同节点。
3.2 HDFS容错原理
在文件写入 HDFS 时
-
HDFS 会首先把文件分割成块，并把这些数据块存储在集群不同机器上 - 然后在其他机器创建各个块的副本，默认情况下，
HDFS 会在其他机器创建3个文件的副本
所以，HDFS 集群任意机器挂了，我们依然能从其他保存数据副本的机器上读取数据，由于这种独特的分布式存储特性，HDFS 给我们提供了更快的文件读写机制。
04 文末
本文主要讲解HDFS的高可用和容错机制的原理，谢谢大家的阅读，本文完！
参阅文献：
- https://www.hadoopdoc.com/hdfs/hdfs-high-available-fault-tolerant
