分布式文件系统学习
- 格式：doc
- 大小：452.00 KB
- 文档页数：23
分布式基础学习所谓分布式，在这里，很狭义的指代以 Google 的三驾马车，GFS、Map/Reduce、BigTable 为框架核心的分布 式存储和计算系统。
通常如我一样初学的人，会以 Google 这几份经典的论文作为开端的。
它们勾勒出了分布式存 储和计算的一个基本蓝图，已可窥见其几分风韵，但终究还是由于缺少一些实现的代码和示例，色彩有些斑驳，缺 少了点感性。
幸好我们还有 Open Source，还有 Hadoop。
Hadoop 是一个基于 Java 实现的，开源的，分布式 存储和计算的项目。
作为这个领域最富盛名的开源项目之一，它的使用者也是大牌如云，包括了 Yahoo，Amazon， Facebook 等等（好吧，还可能有校内，不过这真的没啥分量...）。
Hadoop 本身，实现的是分布式的文件系统 HDFS，和分布式的计算（Map/Reduce）框架，此外，它还不是一个人在战斗，Hadoop 包含一系列扩展项目， 包括了分布式文件数据库 HBase（对应 Google 的 BigTable），分布式协同服务 ZooKeeper（对应 Google 的 Chubby），等等。
如此，一个看上去不错的黄金搭档浮出水面，Google 的论文 + Hadoop 的实现，顺着论文的框架看具体的实现， 用实现来进一步理解论文的逻辑，看上去至少很美。
网上有很多前辈们，做过 Hadoop 相关的源码剖析工作，我关 注最多的是这里，目前博主已经完成了 HDFS 的剖析工作，Map/Reduce 的剖析正火热进行中，更新频率之高， 剖析之详尽，都是难得一见的，所以，走过路过一定不要错过了。
此外，还有很多 Hadoop 的关注者和使用者贴过 相关的文章， 比如： 这里，这里。
也可以去 Hadoop 的中文站点（不知是民间还是官方...） ，搜罗一些学习资料。
。
我个人从上述资料中受益匪浅，而我自己要做的整理，与原始的源码剖析有些不同，不是依照实现的模块，而是基 于论文的脉络和实现这样系统的基本脉络来进行的，也算，从另一个角度给出一些东西吧。
鉴于个人对于分布式系 统的理解非常的浅薄，缺少足够的实践经验，深入的问题就不班门弄斧了，仅做梳理和解析，大牛至此，可绕路而 行了。
一. 分布式文件系统分布式文件系统，在整个分布式系统体系中处于最低层最基础的地位，存储嘛，没了数据，再好的计算平台，再完 善的数据库系统，都成了无水之舟了。
那么，什么是分布式文件系统，顾名思义，就是分布式 文件系统 分布式+文件系统 分布式 文件系统。
它包含 这两个方面的内涵，从文件系统的客户使用的角度来看，它就是一个标准的文件系统，提供了一系列 API，由此进 行文件或目录的创建、移动、删除，以及对文件的读写等操作。
从内部实现来看，分布式的系统则不再和普通文件 系统一样负责管理本地磁盘， 它的文件内容和目录结构都不是存储在本地磁盘上， 而是通过网络传输到远端系统上。
并且，同一个文件存储不只是在一台机器上，而是在一簇机器上分布式存储，协同提供服务，正所谓分布式。
因此，考量一个分布式文件系统的实现，其实不妨可以从这两方面来分别剖析，而后合二为一。
首先，看它如何去 实现文件系统所需的基本增删改查的功能。
然后，看它如何考虑分布式系统的特点，提供更好的容错性，负载平衡， 等等之类的。
这二者合二为一，就明白了一个分布式文件系统，整体的实现模式。
I. 术语对照说任何东西，都需要统一一下语言先，不然明明说的一个意思，却容易被理解到另一个地方去。
Hadoop 的分布式 文件系统 HDFS，基本是按照 Google 论文中的 GFS 的架构来实现的。
但是，HDFS 为了彰显其不走寻常路的本 性，其中的大量术语，都与 GFS 截然不同。
明明都是一个枝上长的土豆，它偏偏就要叫山药蛋，弄得水火不容的， 苦了我们看客。
秉承老好人，谁也不得罪的方针，文中，既不采用 GFS 的叫法，也不采用 Hadoop 的称谓，而是 另辟蹊径，自立门户，搞一套自己的中文翻译，为了避免不必要的痛楚，特此先来一帖术语对照表，要不懂查一查， 包治百病。
文中所用翻译 主控服务器HDFS 中的术语 NameNodeGFS 中的术语 Master术语解释 整个文件系统的大脑，它1提供整个文件系统的目 录信息，并且管理各个数 据服务器。
分布式文件系统中的每 一个文件，都被切分成若 干个数据块，每一个数据 块都被存储在不同的服 务器上，此服务器称之为 数据服务器。
每个文件都会被切分成 若干个块，每一块都有连 续的一段文件内容，是存 储的基恩单位，在这里统 一称做数据块。
客户端写文件的时候，不 是一个字节一个字节写 入文件系统的，而是累计 到一定数量后，往文件系 统中写入一次，每发送一 次的数据，都称为一个数 据包。
在每一个数据包中，都会 将数据切成更小的块，每 一个块配上一个奇偶校 验码，这样的块，就是传 输块。
备用的主控服务器，在身 后默默的拉取着主控服 务器 的日志，等待主控 服务器牺牲后被扶正。
数据服务器DataNodeChunk Server数据块BlockChunk数据包Packet无传输块Chunk无备份主控服务器SecondaryNameNode 无*注：本文采用的 Hadoop 是 0.19.0 版本。
注II. 基本架构1. 服务器介绍 与单机的文件系统不同，分布式文件系统不是将这些数据放在一块磁盘上，由上层操作系统来管理。
而是存放在一 个服务器集群上，由集群中的服务器，各尽其责，通力合作，提供整个文件系统的服务。
其中重要的服务器包括： 主控服务器（Master/NameNode），数据服务器 数据服务器（ChunkServer/DataNode），和客户服务器 客户服务器。
HDFS 和 GFS 主控服务器 数据服务器 客户服务器 都是按照这个架构模式搭建的。
个人觉得，其中设计的最核心内容是：文件的目录结构独立存储在一个主控服务器 文件的目录结构独立存储在一个主控服务器 上，而具体文件数据，拆分成若干块，冗余的存放在不同的数据服务器上。
而具体文件数据，拆分成若干块， 冗余的存放在不同的数据服务器上。
存储目录结构的主控服务器，在 GFS 中称为 Master，在 HDFS 中称为 NameNode。
这两个名字，叫得都有各 自的理由，是瞎子摸象各表一面。
Master 是之于数据服务器来叫的，它做为数据服务器的领导同志存在，管理各 个数据服务器，收集它们的信息，了解所有数据服务器的生存现状，然后给它们分配任务，指挥它们齐心协力为系2统服务；而 NameNode 是针对客户端来叫的，对于客户端而言，主控服务器上放着所有的文件目录信息，要找一 个文件，必须问问它，由此而的此名。
主控服务器在整个集群中，同时提供服务的只存在一个，如果它不幸牺牲的话，会有后备军立刻前赴后继的跟上， 但，同一时刻，需要保持一山不容二虎的态势。
这种设计策略，避免了多台服务器间即时同步数据的代价，而同时， 它也使得主控服务器很可能成为整个架构的瓶颈所在。
因此，尽量为主控服务器减负，不然它做太多的事情，就自 因此，尽量为主控服务器减负，不然它做太多的事情， 因此 然而然的晋升成了一个分布式文件系统的设计要求。
然而然的晋升成了一个分布式文件系统的设计要求 每一个文件的具体数据，被切分成若干个数据块，冗余的存放在数据服务器。
通常的配置，每一个数据块的大小为 64M，在三个数据服务器上冗余存放（这个 64M，不是随便得来的，而是经过反复实践得到的。
因为如果太大， 容易造成热点的堆叠，大量的操作集中在一台数据服务器上，而如果太小的话，附加的控制信息传输成本，又太高 了。
因此没有比较特定的业务需求，可以考虑维持此配置...）。
数据服务器是典型的四肢发达头脑简单的苦力，其 其 主要的工作模式就是定期向主控服务器汇报其状况，然后等待并处理命令，更快更安全的存放好数据 主要的工作模式就是定期向主控服务器汇报其状况，然后等待并处理命令，更快更安全的存放好数据。
此外，整个分布式文件系统还有一个重要角色是客户端 客户端。
它不和主控服务和数据服务一样，在一个独立的进程中提 客户端 供服务，它只是以一个类库（包）的模式存在，为用户提供了文件读写、目录操作等 APIs。
当用户需要使用分布 它只是以一个类库（ 它只是以一个类库 的模式存在，为用户提供了文件读写、 式文件系统进行文件读写的时候， 把客户端相关包给配置上， 就可以通过它来享受分布式文件系统提供的服务了。
。
。
2. 数据分布 一个文件系统中，最重要的数据，其实就是整个文件系统的目录结构和具体每个文件的数据。
具体的文件数据被切 分成数据块，存放在数据服务器上。
每一个文件数据块，在数据服务器上都表征为出双入队的一对文件（这是普通 的 Linux 文件），一个是数据文件，一个是附加信息的元文件，在这里，不妨把这对文件简称为数据块文件 数据块文件。
数据 数据块文件 块文件存放在数据目录 数据目录下，它有一个名为 current 的根目录，然后里面有若干个数据块文件和从 dir0-dir63 的最 数据目录 多 64 个的子目录，子目录内部结构等同于 current 目录，依次类推（更详细的描述，参见这里）。
个人觉得，这 样的架构，有利于控制同一目录下文件的数量，加快检索速度。
这是磁盘上的物理结构， 与之对应的， 是内存中的数据结构， 用以表征这样的磁盘结构， 方便读写操作的进行。
Block 类用于表示数据块，而 FSDataset 类是数据服务器管理文件块的数据结构，其中，FSDataset.FSDir 对应着数 据块文件和目录，FSDataset.FSVolume 对应着一个数据目录，FSDataset.FSVolumeSet 是 FSVolume 的集合，每一个 FSDataset 有一个 FSVolumeSet。
多个数据目录，可以放在不同的磁盘上，这样有利于加快磁 盘操作的速度。
相关的类图，可以参看这里 。
此外，与 FSVolume 对应的，还有一个数据结构，就是 DataStorage，它是 Storage 的子类，提供了升级、 回滚等支持。
但与 FSVolume 不一样，它不需要了解数据块文件的具体内容，它只知道有这么一堆文件放这里，会 有不同版本的升级需求， 它会处理怎么把它们升级回滚之类的业务 （关于 Storage， 可以参见这里） 而 FSVolume 。
提供的接口，都基本上是和 Block 相关的。
相比数据服务器，主控服务器的数据量不大，但逻辑更为复杂。
主控服务器主要有三类数据：文件系统的目录结构 文件系统的目录结构 数据，各个文件的分块信息 数据块的位置信息 数据 各个文件的分块信息，数据块的位置信息 各个文件的分块信息 数据块的位置信息（就数据块放置在哪些数据服务器上...）。
