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
下面是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和更多走在这条路上同行者交流，有兴趣可关注一下，谢谢。
版权声明：本文为博主原创文章，未经博主允许不得转载。
