HDFS的高可用架构是怎样工作的

在HDFS分布式文件系统中，NameNode是系统的核心节点，它存储了各类元数据信息，并负责管理文件系统的命名空间和客户端对文件的访问。但是，在Hadoop10版本中，NameNode只有一个，一旦这个NameNode发生故障，就会导致整个Hadoop集群不可用，也就是发生了单点故障问题。

为了解决单点故障问题，Hadoop20中的HDFS中增加了对高可用的支持。在高可用的HDFS集群中，通常有两台或者两台以上的机器充当NameNode，在任意时间内，都要保证至少有一台机器处于活动(Active)状态，一台机器处于备用(Standby)状态。处于活动状态的NameNode负责处理客户端请求，而处于备用状态的NameNode则处于“随时待命”状态。一旦处于活动状态NameNode节点发生故障，那么处于备用状态的NameNode会立即接管它的任务并开始处理客户端请求，保证业务不会出现明显中断，不影响系统的正常对外服务。接下来，通过一张图来描述HDFS的高可用架构，如图1所示。

图1 HDFS的高可用架构

图1所示的高可用架构中，共包含了两个NameNode，其中一个处于活动状态，一个处于备用状态，活跃状态的NameNode将更新的数据写入共享存储系统中，备用状态的NameNode会一直监听共享存储系统，一旦发现有新的数据，就会立即从共享存储系统中将这些数据加载到自己内存中，从而保证与活跃状态的数据同步。

Zookeeper是一种在HDFS高可用集群中集中提供自动故障转移功能的服务，它为每个NameNode都分配了一个故障恢复控制器(Zookeeper Failover Controller，简称ZKFC)，该控制器用于监控NameNode的健康状态，并通过“心跳”方式定期和Zookeeper保持通信。一旦NameNode发生故障，Zookeeper会通知备用状态的NameNode启动，使其成为活动状态去处理客户端请求，从而实现高可用。

转自： >

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。

用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。

Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。

Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了计算。

广义的Hadoop，一般称为Hadoop生态系统，如下所示。

Hadoop生态系统中这些软件的作用：

HDFS 采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点（NameNode）和若干个数据节点（DataNode）。

HDFS采用Java语言开发，因此任何支持JVM的机器都可以部署名称节点和数据节点。

在配置好Hadoop 集群之后，可以通过浏览器访问 >

HDFS是一个主从架构。

Rack代表机架

一个机架一般是10台服务器，或者是5台带GPU的服务器。

在CDH中一般不会让机架发挥作用，默认都是default机架。

1、NN：名称节点

存储: 文件系统的命名空间

a文件名称

b文件目录结构

c文件属性(权限、创建时间、副本数)

d文件对应的那些块(副本块)--->块对应在哪些DN节点上

不会持久化存储这个map映射关系，一般是集群启动和运行时。

dn定期发送blockreport给NN，那么NN就在内存中动态维护这种映射关系

主要作用: 管理文件系统的命名空间

2、DN:数据节点

存储: 数据块和数据块校验

与NN通信

a每隔3秒发送一个心跳包，dfsheartbeatinterval参数

b每隔6小时发送一次blockreport 块报告，dfsblockreportintervalMsec 21600000ms=6小时。

主要作用: 读写文件的数据块

3、SNN:第二数据节点

主要作用: 定期合并NN节点的fsimage+editlog为新的fsimage,推送给NN，简称检查点 checkpoint。

一个小时一次，或者达到1000000次事务

dfsnamenodecheckpointperiod 3600s

dfsnamenodecheckpointtxns 1000000

NN:

SNN:

具体流程：

1滚动新的editlog文件 edits_inprogress_0000000000000000407

2将edits_0000000000000000405-0000000000000000406。fsimage_0000000000000000404 拷贝到snn节点

3合并为新的image fsimage_0000000000000000406

4将检查点的fsimage_0000000000000000406文件推送给nn

5滚动edits_inprogress_0000000000000000407 写满，就滚动到下一个editlog 比如edits_inprogress_0000000000000000408。

第一个副本:

提交节点为DN，自己写一份；

否则为集群外提交，则随机挑选一个不太慢、cpu不太忙的节点上

第二个副本：

放置在于第一个副本的不同机架的节点上

第三个副本:

与第二个副本相同机架的不同节点上

Hadoop

文件系统：文件系统是用来存储和管理文件，并且提供文件的查询、增加、删除等 *** 作。

直观上的体验：在shell窗口输入 ls 命令，就可以看到当前目录下的文件夹、文件。

文件存储在哪里？硬盘

一台只有250G硬盘的电脑，如果需要存储500G的文件可以怎么办？先将电脑硬盘扩容至少250G，再将文件分割成多块，放到多块硬盘上储存。

通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件，就像本地的ls命令一样。

HDFS在客户端上提供了查询、新增和删除的指令，可以实现将分布在多台机器上的文件系统进行统一的管理。

在分布式文件系统中，一个大文件会被切分成块，分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子，这500G的文件会按照一定的大小被切分成若干块，然后分别存储在若干台机器上，然后提供统一的 *** 作接口。

看到这里，不少人可能会觉得，分布式文件系统不过如此，很简单嘛。事实真的是这样的么？

潜在问题

假如我有一个1000台机器组成的分布式系统，一台机器每天出现故障的概率是01%，那么整个系统每天出现故障的概率是多大呢？答案是(1-01%)^1000=63%，因此需要提供一个容错机制来保证发生差错时文件依然可以读出，这里暂时先不展开介绍。

如果要存储PB级或者EB级的数据，成千上万台机器组成的集群是很常见的，所以说分布式系统比单机系统要复杂得多呀。

这是一张HDFS的架构简图：

client通过nameNode了解数据在哪些DataNode上，从而发起查询。此外，不仅是查询文件，写入文件的时候也是先去请教NameNode，看看应该往哪个DateNode中去写。

为了某一份数据只写入到一个Datanode中，而这个Datanode因为某些原因出错无法读取的问题，需要通过冗余备份的方式来进行容错处理。因此，HDFS在写入一个数据块的时候，不会仅仅写入一个DataNode，而是会写入到多个DataNode中，这样，如果其中一个DataNode坏了，还可以从其余的DataNode中拿到数据，保证了数据不丢失。

实际上，每个数据块在HDFS上都会保存多份，保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。

接下来我们来看一下完整的文件写入的流程：

大文件要写入HDFS，client端根据配置将大文件分成固定大小的块，然后再上传到HDFS。

读取文件的流程：

1、client询问NameNode，我要读取某个路径下的文件，麻烦告诉我这个文件都在哪些DataNode上？

2、NameNode回复client，这个路径下的文件被切成了3块，分别在DataNode1、DataNode3和DataNode4上

3、client去找DataNode1、DataNode3和DataNode4，拿到3个文件块，通过stream读取并且整合起来

文件写入的流程：

1、client先将文件分块，然后询问NameNode，我要写入一个文件到某个路径下，文件有3块，应该怎么写？

2、NameNode回复client，可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上，记住，每个块重复写3份，总共是9份

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把数据写到他们上面

出于容错的考虑，每个数据块有3个备份，但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力，这个点是否有更好的解决方案呢？回忆一下mysql主备之间是通过binlog文件进行同步的，HDFS当然也可以借鉴这个思想，数据其实只需要写入到一个datanode上，然后由datanode之间相互进行备份同步，减少了client端的写入压力，那么至于是一个datanode写入成功即成功，还是需要所有的参与备份的datanode返回写入成功才算成功，是可靠性配置的策略，当然这个设置会影响到数据写入的吞吐率，我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。

潜在问题

NameNode确实会回放editlog，但是不是每次都从头回放，它会先加载一个fsimage，这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照，然后再在这个基础上回放editlog，完成后，会清空editlog，再把当前文件元数据的内存状态写入fsimage，方便下一次加载。

这样，全量回放就变成了增量回放，但是如果NameNode长时间未重启过，editlog依然会比较大，恢复的时间依然比较长，这个问题怎么解呢？

SecondNameNode是一个NameNode内的定时任务线程，它会定期地将editlog写入fsimage，然后情况原来的editlog，从而保证editlog的文件大小维持在一定大小。

NameNode挂了， SecondNameNode并不能替代NameNode，所以如果集群中只有一个NameNode，它挂了，整个系统就挂了。hadoop2x之前，整个集群只能有一个NameNode，是有可能发生单点故障的，所以hadoop1x有本身的不稳定性。但是hadoop2x之后，我们可以在集群中配置多个NameNode，就不会有这个问题了，但是配置多个NameNode，需要注意的地方就更多了，系统就更加复杂了。

俗话说“一山不容二虎”，两个NameNode只能有一个是活跃状态active，另一个是备份状态standby，我们看一下两个NameNode的架构图。

两个NameNode通过JournalNode实现同步editlog，保持状态一致可以相互替换。

因为active的NameNode挂了之后，standby的NameNode要马上接替它，所以它们的数据要时刻保持一致，在写入数据的时候，两个NameNode内存中都要记录数据的元信息，并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的，并且standby NameNode实现了SecondNameNode的功能。

进行数据同步 *** 作的过程如下：

active NameNode有 *** 作之后，它的editlog会被记录到JournalNode中，standby NameNode会从JournalNode中读取到变化并进行同步，同时standby NameNode会监听记录的变化。这样做的话就是实时同步了，并且standby NameNode就实现了SecondNameNode的功能。

优点：

缺点：

以上就是关于HDFS的高可用架构是怎样工作的全部的内容，包括:HDFS的高可用架构是怎样工作的、HDFS详解、Hadoop生态系统-新手快速入门（含HDFS、HBase系统架构）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！