相比于基于P2P模型的分布式文件系统架构，HDFS采用的是基于Master/Slave主从架构的分布式文件系统，一个HDFS集群包含一个单独的Master节点和多个Slave节点服务器，这里的一个单独的Master节点的含义是HDFS系统中只存在一个逻辑上的Master组件。一个逻辑的Master节点可以包括两台物理主机，即两台Master服务器、多台Slave服务器。一台Master服务器组成单NameNode集群，两台Master服务器组成双NameNode集群，并且同时被多个客户端访问.所有的这此机器通常都是普通的Linux机器，运行着用户级别(user-level)的服务进程。HDFS架构设计图如下：

　　上图展示了HDFS的NameNode、 DataNode以及客户端之间的存取访问关系，单一节点的NameNode大大简化了系统架构。NameNode负责保存和管理所有的HDFS元数据，因而用户数据就不需要通过NameNode，也就是说文件数据的读写是直接在DataNode上进行的。HDFS存储的文件都被分割成固定大小的Block，在创建Block的时候，NameNode服务器会给每个Block分配一个唯一不变的Block标识。DataNode服务器把Block以Linux文件的形式保存在本地硬盘上，并且根据指定的Block标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个DataNode服务器上。在默认情况下，HDFS使用三个冗余备份，当然用户可以为不同的文件命名空间设定不同的复制因子数。NameNode管理所有的文件系统元数据。这些元数据包括名称空间、访问控制信息、文件和Block的映射信息，以及当前Block的位置信息。NameNode还管理着系统范围内的活动，比如，Block租用管理、孤立Block的I回收，以及Block 在 DataNode服务器之间的迁移。NameNode使信息周期性地和每个DataNode服务器通信，发送指令到各个DataNode服务器并接收DataNode中Block的状态信息。

　　HDFS客户端代码以库的形式被链接到客户程序中。在客户端代码中需要实现HDFS文件系统的API 接口函数，应用程序与NameNode和DataNode服务器通信，以及对数据进行读写操作。客户端和NameNode的通信只获取元数据，所有的数据操作都是由客户端直接和DataNode服务器进行交互的。HDFS不提供POSIX标准的API功能，因此，HDFS API调用不需要深入到Linux vnode级别。无论是客户端还是DataNode服务器都不需要缓存文件数据。客户端缓存数据几乎没有什么用处，因为大部分程序要么以流的方式读取一个巨大的文件，要么工作集太大根本无法被缓存。因此，无须考虑与缓存相关的问题，同时也简化了客户端及整个系统的设计和实现。

本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/5081550.html，如需转载请自行联系原作者