后端分布式系列：分布式存储－HDFS 架构解析

本文以 Hadoop 提供的分布式文件系统（HDFS）为例来进一步展开解析分布式存储服务架构设计的要点。

架构目标

任何一种软件框架或服务都是为了解决特定问题而产生的。还记得我们在 《分布式存储 - 概述》一文中描述的几个关注方面么？分布式文件系统属于分布式存储中的一种面向文件的数据模型，它需要解决单机文件系统面临的容量扩展和容错问题。

所以 HDFS 的架构设计目标就呼之欲出了：

面向超大文件或大量的文件数据集

自动检测局部的硬件错误并快速恢复

基于此目标，考虑应用场景出于简化设计和实现的目的，HDFS 假设了一种 write-once-read-many 的文件访问模型。这种一次写入并被大量读出的模型在现实中确实适应很多业务场景，架构设计的此类假设是合理的。正因为此类假设的存在，也限定了它的应用场景。

架构总揽

下面是一张来自官方文档的架构图：



从图中可见 HDFS 的架构包括三个部分，每个部分有各自清晰的职责划分。

NameNode

DataNode

Client

从图中可见，HDFS 采用的是中心总控式架构，NameNode 就是集群的中心节点。

NameNode

NameNode 的主要职责是管理整个文件系统的元信息（Metadata），元信息主要包括：

File system namesapce

HDFS 类似单机文件系统以目录树的形式组织文件，称为 file system namespace

Replication factor

文件副本数，针对每个文件设置

Mapping of blocks to DataNodes

文件块到数据节点的映射关系

在上面架构图中，指向 NameNode 的 Metadata ops 主要就是针对文件的创建、删除、读取和设置文件的副本数等操作，所以所有的文件操作都绕不过 NameNode。除此之外 NameNode 还负责管理 DataNode，如新的 DataNode 加入集群，旧的 DataNode 退出集群，在 DataNode 之间负载均衡文件数据块的分布等等。更多关于 NameNode 的设计实现分析，后面会单独成文详解。

DataNode

DataNode 的职责如下：

存储文件块（block）

服务响应 Client 的文件读写请求

执行文件块的创建、删除和复制

从架构图上看到有个 Block ops 的操作箭头从 NameNode 指向 DataNode，会让人误以为 NameNode 会主动向 DataNode 发出指令调用。实际上 NameNode 从不调用 DataNode，仅仅是通过 DataNode 定期向 NameNode 发送心跳来携带回传的指令信息。

架构图上专门标记了 Rack1 和 Rack2，表明了 HDFS 在考虑文件数据块的多副本分布时针对机架感知作了专门设计，细节我们这里先不展开，更多关于 DataNode 的设计实现分析，后面会单独成文详解。

Client

考虑到 HDFS 交互过程的复杂性，所以特地提供了针特定编程语言的 Client 以简化使用。Client 的职责如下：

提供面向应用编程语言的一致 API，简化应用编程

改善访问性能

Client 之所以能够改善性能是因为针对读可以提供缓存（cache），针对写可以通过缓冲（buffer）批量方式，细节我们这里也先不展开，更多关于 Client 的设计实现分析，后面会单独成文详解。

总结

本来想在一篇文章里写完 HDFS 架构解析的，写着写着发现不太可能。作为分布式系统中最复杂的分布式存储类系统，每一个架构设计权衡的实现细节点，都值得好好推敲，一旦展开此文感觉就会长的没完没了，所以这里先总体过一下，针对每个部分的设计实现细节再以主题文章来详细解析。

参考

［1］Hadoop Documentation. HDFS Architecture.

［2］Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas. The Hadoop Distributed File System

下面是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和更多走在这条路上同行者交流，有兴趣可关注一下，谢谢。