分布式基础学习（1）--分布式文件系统
分布式基础学习html
所谓分布式，在这里，很狭义的指代以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），等等。。。java
如此，一个看上去不错的黄金搭档浮出水面，Google的论文 + Hadoop的实现，顺着论文的框架看具体的实现，用实现来进一步理解论文的逻辑，看上去至少很美。网上有不少前辈们，作过Hadoop相关的源码剖析工做，我关注最多的是这里，目前博主已经完成了HDFS的剖析工做，Map/Reduce的剖析正火热进行中，更新频率之高，剖析之详尽，都是可贵一见的，因此，走过路过必定不要错过了。此外，还有不少Hadoop的关注者和使用者贴过相关的文章，好比：这里，这里。也能够去Hadoop的中文站点（不知是民间仍是官方...），搜罗一些学习资料。。。node
我 我的从上述资料中受益不浅，而我本身要作的整理，与原始的源码剖析有些不一样，不是依照实现的模块，而是基于论文的脉络和实现这样系统的基本脉络来进行的， 也算，从另外一个角度给出一些东西吧。鉴于我的对于分布式系统的理解很是的浅薄，缺乏足够的实践经验，深刻的问题就不班门弄斧了，仅作梳理和解析，大牛至 此，可绕路而行了。。。算法
一. 分布式文件系统数据库
分 布式文件系统，在整个分布式系统体系中处于最低层最基础的地位，存储嘛，没了数据，再好的计算平台，再完善的数据库系统，都成了无水之舟了。那么，什么是 分布式文件系统，顾名思义，就是分布式+文件系统。它包含这两个方面的内涵，从文件系统的客户使用的角度来看，它就是一个标准的文件系统，提供了一系列 API，由此进行文件或目录的建立、移动、删除，以及对文件的读写等操做。从内部实现来看，分布式的系统则再也不和普通文件系统同样负责管理本地磁盘，它的 文件内容和目录结构都不是存储在本地磁盘上，而是经过网络传输到远端系统上。而且，同一个文件存储不仅是在一台机器上，而是在一簇机器上分布式存储，协同 提供服务，正所谓分布式。。。apache
因 此，考量一个分布式文件系统的实现，其实不妨能够从这两方面来分别剖析，然后合二为一。首先，看它如何去实现文件系统所需的基本增删改查的功能。而后，看 它如何考虑分布式系统的特色，提供更好的容错性，负载平衡，等等之类的。这两者合二为一，就明白了一个分布式文件系统，总体的实现模式。。。数组
I. 术语对照缓存
说 任何东西，都须要统一一下语言先，否则明明说的一个意思，却容易被理解到另外一个地方去。Hadoop的分布式文件系统HDFS，基本是按照Google论 文中的GFS的架构来实现的。可是，HDFS为了彰显其不走寻常路的本性，其中的大量术语，都与GFS大相径庭。明明都是一个枝上长的土豆，它恰恰就要叫 山药蛋，弄得水火不容的，苦了咱们看客。秉承老好人，谁也不得罪的方针，文中，既不采用GFS的叫法，也不采用Hadoop的称谓，而是另辟蹊径，自立门 户，搞一套本身的中文翻译，为了不没必要要的痛楚，特此先来一帖术语对照表，要不懂查一查，包治百病。。。安全
| 文中所用翻译服务器 |
HDFS中的术语 |
GFS中的术语 |
术语解释 |
| 主控服务器 |
NameNode |
Master |
整个文件系统的大脑，它提供整个文件系统的目录信息，而且管理各个数据服务器。 |
| 数据服务器 |
DataNode |
Chunk Server |
分布式文件系统中的每个文件，都被切分红若干个数据块，每个数据块都被存储在不一样的服务器上，此服务器称之为数据服务器。 |
| 数据块 |
Block |
Chunk |
每一个文件都会被切分红若干个块，每一块都有连续的一段文件内容，是存储的基恩单位，在这里统一称作数据块。 |
| 数据包 |
Packet |
无 |
客户端写文件的时候，不是一个字节一个字节写入文件系统的，而是累计到必定数量后，往文件系统中写入一次，每发送一次的数据，都称为一个数据包。 |
| 传输块 |
Chunk |
无 |
在每个数据包中，都会将数据切成更小的块，每个块配上一个奇偶校验码，这样的块，就是传输块。 |
| 备份主控服务器 |
SecondaryNameNode |
无 |
备用的主控服务器，在身后默默的拉取着主控服务器 的日志，等待主控服务器牺牲后被扶正。 |
*注：本文采用的Hadoop是0.19.0版本。
II. 基本架构
1. 服务器介绍
与 单机的文件系统不一样，分布式文件系统不是将这些数据放在一块磁盘上，由上层操做系统来管理。而是存放在一个服务器集群上，由集群中的服务器，各尽其责，通 力合做，提供整个文件系统的服务。其中重要的服务器包括：主控服务器（Master/NameNode），数据服务器（ChunkServer /DataNode），和客户服务器。HDFS和GFS都是按照这个架构模式搭建的。我的以为，其中设计的最核心内容是：文件的目录结构独立存储在一个主 控服务器上，而具体文件数据，拆分红若干块，冗余的存放在不一样的数据服务器上。
存 储目录结构的主控服务器，在GFS中称为Master，在HDFS中称为NameNode。这两个名字，叫得都有各自的理由，是瞎子摸象各表一面。 Master是之于数据服务器来叫的，它作为数据服务器的领导同志存在，管理各个数据服务器，收集它们的信息，了解全部数据服务器的生存现状，而后给它们 分配任务，指挥它们齐心合力为系统服务；而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相关的。。。
相 比数据服务器，主控服务器的数据量不大，但逻辑更为复杂。主控服务器主要有三类数据：文件系统的目录结构数据，各个文件的分块信息，数据块的位置信息（就 数据块放置在哪些数据服务器上...）。在GFS和HDFS的架构中，只有文件的目录结构和分块信息才会被持久化到本地磁盘上，而数据块的位置信息则是通 过动态汇总过来的，仅仅存活在内存数据结构中，机器挂了，就灰飞烟灭了。每个数据服务器启动后，都会向主控服务器发送注册消息，将其上数据块的情况都告 知于主控服务器。俗话说，简单就是美，根据DRY原则，保存的冗余信息越少，出现不一致的可能性越低，付出一点点时间的代价，换取了一大把逻辑上的简单 性，绝对应该是一个包赚不赔的买卖。。。
在 HDFS中，FSNamespacesystem类就负责保管文件系统的目录结构以及每一个文件的分块情况的，其中，前者是由FSDirectory类来负 责，后者是各个INodeFile自己维护。在INodeFile里面，有一个BlockInfo的数组，保存着与该文件相关的全部数据块信 息，BlockInfo中包含了从数据块到数据服务器的映射，INodeFile只须要知道一个偏移量，就能够提供相关的数据块，和数据块存放的数据服务 器信息。。。
三、服务器间协议
在 Hadoop的实现中，部署了一套RPC机制，以此来实现各服务间的通讯协议。在Hadoop中，每一对服务器间的通讯协议，都定义成为一个接口。服务端 的类实现该接口，而且创建RPC服务，监听相关的接口，在独立的线程处理RPC请求。客户端则能够实例化一个该接口的代理对象，调用该接口的相应方法，执 行一次同步的通讯，传入相应参数，接收相应的返回值。基于此RPC的通讯模式，是一个消息拉取的流程，RPC服务器等待RPC客户端的调用，而不会先发制 人主动把相关信息推送到RPC客户端去。。。
其 实RPC的模式和原理，实在是没啥好说的，之因此说，是由于能够经过把握好这个，完全理顺Hadoop各服务器间的通讯模式。Hadoop会定义一些列的 RPC接口，只须要看谁实现，谁调用，就能够知道谁和谁通讯，都作些啥事情，图中服务器的基本架构、各服务所使用的协议、调用方向、以及协议中的基本内 容。。。
III. 基本的文件操做
基 本的文件操做，能够分红两类，一个是对文件目录结构的操做，好比文件和目录的建立、删除、移动、改名等等；另外一个是对文件数据流的操做，包括读取和写入文 件数据。固然，文件读和写，是有本质区别的，尤为是在数据冗余的状况下，所以，当成两类操做也不足为过。此外，要具体到读写的类别，也是能够再继续分类下 去的。在GFS的论文中，对于分布式文件系统的读写场景有一个重要的假定（实际上是从实际业务角度得来的...）：就是文件的读取是由大数据量的连续读取和 小数据量的随机读取组成，文件的写入则基本上都是批量的追加写，和偶尔的插入写（GFS中还有大量的假设，它们构成了分布式文件系统架构设计的基石。每一 个系统架构都是搭建在必定假设上的，这些假设有些来自于实际业务的情况，有些是由于天生的条件约束，不基于假设理解设计，确定会有失偏颇...）。在 GFS中，对文件的写入分红追加写和插入写都有所支持，可是，在HDFS中仅仅支持追加写，这大大下降了复杂性。关于HDFS与GFS的一些不一样，能够参 看这里。。。
1. 文件和目录的操做
文 件目录的信息，所有囤积在主控服务器上，所以，全部对文件目录的操做，只会直接涉及到客户端和主控服务器。整个目录相关的操做流程基本都是这样的：客户端 DFSClient调用ClientProtocol定义的相关函数，该操做经过RPC传送到其实现者主控服务器NameNode那里，NameNode 作相关的处理后（不多...），调用FSNamesystem的相关函数。在FSNamesystem中，每每是作一些验证和租约操做，具体的目录结构操 做交由FSDirectory的相应函数来操做。最后，依次返回，经由RPC传送回客户端。具体各操做涉及到的函数和具体步骤，参见下表：
| 相关操做 |
ClientProtocol / NameNode |
FSNamesystem |
FSDirectory |
关键步骤 |
| 建立文件 |
create |
startFile |
addFile |
1. 检查是否有写权限； |
| 建立目录 |
mkdirs |
mkdirs |
mkdirs |
1. 检查指定目录是不是目录； |
| 更名操做 |
rename |
renameTo |
renameTo |
1. 检查相关路径的权限； |
| 删除操做 |
delete |
delete |
delete |
1. 若是不是递归删除，确认指定路径是不是空目录； |
| 设置权限 |
setPermission |
setPermission |
setPermission |
1. 检查owner判断是否有操做权限； |
| 设置用户 |
setOwner |
setOwner |
setOwner |
1. 检查是否有操做权限； |
| 设置时间 |
setTimes |
setTimes |
setTimes |
1. 检查是否有写权限； |
从 上表能够看到，其实有的操做本质上仍是涉及到了数据服务器，好比文件建立和删除操做。可是，以前提到，主控服务器只于数据服务器是一个等待拉取的地位，它 们不会主动联系数据服务器，将指令传输给它们，而是放到相应的数据结构中，等待数据服务器来取。这样的设计，能够减小通讯的次数，加快操做的执行速 度。。。
另，上述步骤中，有些日志和租约相关的操做，从概念上来讲，和目录操做其实没有任何联系，可是，为了知足分布式系统的需求，这些操做是很是有必要的，在此，按下不表。。。
二、文件的读取
不管是文件读取，仍是文件的写入，主控服务器扮演的都是中介的角色。客户端把本身的需求提交给主控服务器，主控服务器挑选合适的数据服务器，介绍给客户端，让客户端和数据服务器单聊，要读要写随大家便。这种策略相似于DMA，下降了主控服务器的负载，提升了效率。。。
因 此，在文件读写操做中，最主要的通讯，发生在客户端与数据服务器之间。它们之间跑的协议是ClientDatanodeProtocol。从这个协议中 间，你没法看到和读写相关的接口，由于，在Hadoop中，读写操做是不走RPC机制的，而是另立门户，独立搭了一套通讯框架。在数据服务器一 端，DataNode类中有一个DataXceiverServer类的实例，它在一个单独的线程等待请求，一旦接到，就启动一个DataXceiver 的线程，处理这次请求。一个请求一个线程，对于数据服务器来讲，逻辑上很简单。当下，DataXceiver支持的请求类型有六种，具体的请求包和回复包 格式，请参见这里，这里，这里。在Hadoop的实现中，并无用类来封装这些请求，而是按流的次序写下来，这给代码阅读带来挺多的麻烦，也对代码的维护带来必定的困难，不知道是出于何种考虑。。。
相 比于写，文件的读取实在是一个简单的过程。在客户端DFSClient中，有一个DFSClient.DFSInputStream类。当须要读取一个文 件的时候，会生成一个DFSInputStream的实例。它会先调用ClientProtocol定义getBlockLocations接口，提供给 NameNode文件路径、读取位置、读取长度信息，从中取得一个LocatedBlocks类的对象，这个对象包含一组LocatedBlock，那里 面有所规定位置中包含的全部数据块信息，以及数据块对应的全部数据服务器的位置信息。当读取开始后，DFSInputStream会先尝试从某个数据块对 应的一组数据服务器中选出一个，进行链接。这个选取算法，在当下的实现中，很是简单，就是选出第一个未挂的数据服务器，并无加入客户端与数据服务器相对 位置的考量。读取的请求，发送到数据服务器后，天然会有DataXceiver来处理，数据被一个包一个包发送回客户端，等到整个数据块的数据都被读取完 了，就会断开此连接，尝试链接下一个数据块对应的数据服务器，整个流程，依次如此反复，直到全部想读的都读取完了为止。。。
三、文件的写入
文件读取是一个一对一的过程，一个客户端，只须要与一个数据服务器联系，就能够得到所需的内容。可是，写入操做，则是一个一对多的流程。一次写入，须要在全部存放相关数据块的数据服务器都保持同步的更新，有任何的差池，整个流程就告失败。。。
在 分布式系统中，一旦涉及到写入操做，并发处理不免都会沦落成为一个变了相的串行操做。由于，若是不一样的客户端若是是任意时序并发写入的话，整个写入的次序 没法保证，可能你写半条记录我写半条记录，最后出来的结果乱七八糟不可估量。在HDFS中，并发写入的次序控制，是由主控服务器来把握的。当建立、续写一 个文件的时候，该文件的节点类，由INodeFile升级成为 INodeFileUnderConstruction，INodeFileUnderConstruction是INodeFile的子类，它起到一个 锁的做用。若是当一个客户端想建立或续写的文件是INodeFileUnderConstruction，会引起异常，由于这说明这个此处有爷，请另寻高 就，从而保持了并发写入的次序性。同时，INodeFileUnderConstruction有包含了此时正在操做它的客户端的信息以及最后一个数据块 的数据服务器信息，当追加写的时候能够更快速的响应。。。
与 读取相似，DFSClient也有一个DFSClient.DFSOutputStream类，写入开始，会建立此类的实例。 DFSOutputStream会从NameNode上拿一个LocatedBlock，这里面有最后一个数据块的全部数据服务器的信息。这些数据服务器 每个都须要可以正常工做（对于读取，只要还有一个能工做的就能够实现...），它们会依照客户端的位置被排列成一个有着最近物理距离和最小的序列（物理 距离，是根据机器的位置定下来的...），这个排序问题相似于著名旅行商问题，属于NP复杂度，可是因为服务器数量很少，因此用最粗暴的算法，也并不会看 上去不美。。。
文 件写入，就是在这一组数据服务器上构形成数据流的双向流水线。DFSOutputStream，会与序列的第一个数据服务器创建Socket链接，发送请 求头，而后等待回应。DataNode一样是创建DataXceiver来处理写消息，DataXceiver会依照包中传过来的其余服务器的信息，创建 与下一个服务器的链接，并生成相似的头，发送给它，并等待回包。此流程依次延续，直到最后一级，它发送回包，反向着逐级传递，再次回到客户端。若是一切顺 利，那么此时，流水线创建成功，开始正式发送数据。数据是分红一个个数据包发送的，全部写入的内容，被缓存在客户端，当写满64K，会被封装成 DFSOutputStream.Packet类实例，放入DFSOutputStream的dataQueue队列。 DFSOutputStream.DataStreamer会时刻监听这个队列，一旦不为空，则开始发送，将位于dataQueue队首的包移动到 ackQueue队列的队尾，表示已发送但还没有接受回复的包队列。同时启动ResponseProcessor线程监听回包，直到收到相应回包，才将发送 包从ackQueue中移除，表示成功。每个数据服务器的DataXceiver收到了数据包，一边写入到本地文件中去，一边转发给下一级的数据服务 器，等待回包，同前面创建流水线的流程。。。
当一个数据块写满了以后，客户端须要向主控服务器申请追加新的数据块。这个会引发一次数据块的分配，成功后，会将新的数据服务器组返还给客户端。而后从新回到上述流程，继续前行。。。
关于写入的流程，还能够参见这里。此外，写入涉及到租约问题，后续会仔细的来讲。。。
IV. 分布式支持
如 果单机的文件系统是田里勤恳的放牛娃，那么分布式文件系统就是刀尖上讨饭吃的马贼了。在分布式环境中，有太多的意外，数据随时传输错误，服务器时刻准备牺 牲，不少日常称为异常的现象，在这里都须要按照日常事来对待。所以，对于分布式文件系统而言，仅仅是知足了正常情况下文件系统各项服务还不够，还须要保证 分布式各类意外场景下健康持续的服务，不然，将一无可取。。。
一、服务器的错误恢复
在分布式环境中，哪台服务器牺牲都是常见的事情，牺牲不可怕，可怕的是你都没有时刻准备好它们会牺牲。做为一个合格的分布式系统，HDFS固然时刻准备好了前赴后继奋勇向前。HDFS有三类服务器，每一类服务器出错了，都有相应的应急策略。。。
a. 客户端
生 命最轻如鸿毛的童鞋，应该就是客户端了。毕竟，作为一个文件系统的使用者，在整个文件系统中的地位，不免有些归于三流。而做为客户端，大部分时候，牺牲了 就牺牲了，没人哀悼，无人同情，只有在在辛勤写入的时候，不幸辞世（机器挂了，或者网络断了，诸如此类...），才会引发些恐慌。由于，此时此刻，在主控 服务器上对应的文件，正做为INodeFileUnderConstruction活着，仅仅为占有它的那个客户端服务者，作为一个专注的文件，它不容许 别的客户端染指。这样的话，一旦占有它的客户端服务者牺牲了，此客户端会依然占着茅坑不拉屎，让如花似玉 INodeFileUnderConstruction孤孤单单守寡终身。这种事情固然没法容忍，所以，必须有办法解决这个问题，办法就是：租约。。。
租约，顾名思义，就是当客户端须要占用某文件的时候，与主控服务器签定的一个短时间合同。这个合同有一个期限，在这个期限内，客户端能够延长合同期限，一旦超过时限，主控服务器会强行终止此租约，将这个文件的享用权，分配给他人。。。
在 打开或建立一个文件，准备追加写以前，会调用LeaseManager的addLease方法，在指定的路径下与此客户端签定一份租约。客户端会启动 DFSClient.LeaseChecker线程，定时轮询调用ClientProtocol的renewLease方法，续签租约。在主控服务器一 端，有一个LeaseManager.Monitor线程，始终在轮询检查全部租约，查看是否有到期未续的租约。若是一切正常，该客户端完成写操做，会关 闭文件，中止租约，一旦有所意外，好比文件被删除了，客户端牺牲了，主控服务器都会剥夺此租约，如此，来避免因为客户端停机带来的资源被长期霸占的问 题。。。
b. 数据服务器
当 然，会挂的不仅是客户端，海量的数据服务器是一个更不稳定的因素。一旦某数据服务器牺牲了，而且主控服务器被蒙在鼓中，主控服务器就会变相的欺骗客户端， 给它们没法链接的读写服务器列表，致使它们到处碰壁没法工做。所以，为了整个系统的稳定，数据服务器必须时刻向主控服务器汇报，保持主控服务器对其的彻底 了解，这个机制，就是心跳消息。在HDFS中，主控服务器NameNode实现了DatanodeProtocol接口，数据服务器DataNode会在 主循环中，不停的调用该协议中的sendHeartbeat方法，向NameNode汇报情况。在此调用中，DataNode会将其总体运行情况告知 NameNode，好比：有多少可用空间、用了多大的空间，等等之类。NameNode会记住此DataNode的运行情况，做为新的数据块分配或是负载 均衡的依据。当NameNode处理完成此消息后，会将相关的指令封装成一个DatanodeCommand对象，交还给DataNode，告诉数据服务 器什么数据块要删除什么数据块要新增等等之类，数据服务器以此为本身的行动依据。。。
但 是，sendHeartbeat并无提供本地的数据块信息给NameNode，那么主控服务器就没法知道此数据服务器应该分配什么数据块应该删除什么数 据块，那么它是如何决定的呢？答案就是DatanodeProtocol定义的另外一个方法，blockReport。DataNode也是在主循环中定时 调用此方法，只是，其周期一般比调用sendHeartbeat的更长。它会提交本地的全部数据块情况给NameNode，NameNode会和本地保存 的数据块信息比较，决定什么该删除什么该新增，并将相关结果缓存在本地对应的数据结构中，等待此服务器再发送sendHeartbeat消息过来的时候， 依照这些数据结构中的内容，作出相应的DatanodeCommand指令。blockReport方法一样也会返回一个DatanodeCommand 给DataNode，但一般，只是为空（只有出错的时候不为空），我想，增长缓存，也许是为了确保每一个指令均可以重复发送并肯定被执行。。。
c. 主控服务器
固然，做为整个系统的核心和单点，含辛茹苦的主控服务器含泪西去，整个分布式文件服务集群将完全瘫痪**。如何在主控服务器牺牲后，提拔新的主控服务器并迅速使其进入工做角色，就成了系统必须考虑的问题。解决策略就是：日志。。。
其 实这并非啥新鲜东西，一看就知道是从数据库那儿偷师而来的。在主控服务器上，全部对文件目录操做的关键步骤（具体文件内容所处的数据服务器，是不会被写 入日志的，由于这些内容是动态创建的...），都会被写入日志。另外，主控服务器会在某些时刻，将当下的文件目录完整的序列化到本地，这称为镜像。一旦存 有镜像，镜像前期所写的日志和其余镜像，都纯属冗余，其历史使命已经完成，能够报废删除了。在主控服务器不幸牺牲，或者是战略性的停机修整结束，并从新启 动后，主控服务器会根据最近的镜像 + 镜像以后的全部日志，重建整个文件目录，迅速将服务能力恢复到牺牲前的水准。。。
对于数据服务器而言，它们会经过一些手段，迅速得知顶头上司的更迭消息。它们会马上转投新东家的名下，在新东家旗下注册，并开始向其发送心跳消息，这个机制，可能用分布式协同服务来实现，这里不说也罢。。。
在HDFS的实现中，FSEditLog类是整个日志体系的核心，提供了一大堆方便的日志写入API，以及日志的恢复存储等功能。目前，它支持若干种日志类型，都冠以OP_XXX，并提供相关API，具体能够参见这里。 为了保证日志的安全性，FSEditLog提供了EditLogFileOutputStream类做为写入的承载类，它会同时开若干个本地文件，而后依 次写入，防止日志的损坏致使不可估量的后果。在FSEditLog上面，有一个FSImage类，存储文件镜像并调用FSEditLog对外提供相关的日 志功能。FSImage是Storage类的子类，若是对数据块的讲述有所印象的话，你能够回忆起来，凡事今后类派生出来的东西，都具备版本性质，能够进 行升级和回滚等等，以此，来实现产生镜像是对原有日志和镜像处理的复杂逻辑。。。
目 前，在HDFS的日志系统中，有些地方与GFS的描述有所不一样。在HDFS中，全部日志文件和镜像文件都是本地文件，这就至关于，把日志放在自家的保险箱 中，一旦主控服务器挂了，别的后继而上的服务器也没法拿到这些日志和镜像，用于重振雄风。所以，在HDFS中，运行着一个 SecondaryNameNode服务器，它作为主控服务器的替补，隐忍厚积薄发为篡位作好准备，其中，核心内容就是：按期下载并处理日志和镜像。 SecondaryNameNode看上去像客户端同样，与NameNode之间，走着NamenodeProtocol协议。它会不停的查看主控服务器 上面累计日志的大小，当达到阈值后，调用doCheckpoint函数，此函数的主要步骤包括：
首先是调用startCheckpoint作一些本地的初始化工做；
而后调用rollEditLog，将NameNode上此时操做的日志文件从edit切到edit.new上来，这个操做瞬间完成，上层写日志的函数彻底感受不到差异；
接着，调用downloadCheckpointFiles，将主控服务器上的镜像文件和日志文件都下载到此候补主控服务器上来；
并调用doMerge，打开镜像和日志，将日志生成新的镜像，保存覆盖；
下一步，调用putFSImage把新的镜像上传回NameNode；
再调用rollFsImage，将镜像换成新的，在日志从edit.new更名为edit；
最后，调用endCheckpoint作收尾工做。
整 个算法涉及到NameNode和SecondaryNameNode两个服务器，最终结果是NameNode和SecondaryNameNode都依照 算法进行前的日志生成了镜像。而两个服务器上日志文件的内容，前者是整个算法进行期间所写的日志，后者始终不会有任何日志。当主控服务器牺牲的时候，运行 SecondaryNameNode的服务器马上被扶正，在其上启动主控服务，利用其日志和镜像，恢复文件目录，并逐步接受各数据服务器的注册，最终向外 提供稳定的文件服务。。。
同 样的事情，GFS采用的多是另一个策略，就是在写日志的时候，并不局限在本地，而是同时书写网络日志，即在若干个远程服务器上生成一样的日志。而后， 在某些时机，主控服务器本身，生成镜像，下降日志规模。当主控服务器牺牲，能够在拥有网络日志的服务器上启动主控服务，升级成为主控服务器。。。
GFS与HDFS的策略相比较，前者是化整为零，后者则是批量处理，一般咱们认为，批量处理的平均效率更高一些，且相对而言，可能实现起来容易一些，可是，因为有间歇期，会致使日志的丢失，从而没法100%的将备份主控服务器的状态与主控服务器彻底同步。。。
二、数据的正确性保证
在 复杂纷繁的分布式环境中，咱们坚决的相信，万事皆有可能。哪怕各个服务器都舒舒服服的活着，也可能有各类各样的状况致使网络传输中的数据丢失或者错误。并 且在分布式文件系统中，同一份文件的数据，是存在大量冗余备份的，系统必需要维护全部的数据块内容彻底同步，不然，一人一言，不一样客户端读同一个文件读出 不一样数据，用户非得疯了不可。。。
在 HDFS中，为了保证数据的正确性和同一份数据的一致性，作了大量的工做。首先，每个数据块，都有一个版本标识，在Block类中，用一个长整型的数 generationStamp来表示版本信息（Block类是全部表示数据块的数据结构的基类），一旦数据块上的数据有所变化，此版本号将向前增长。在 主控服务器上，保存有此时每一个数据块的版本，一旦出现数据服务器上相关数据块版本与其不一致，将会触发相关的恢复流程。这样的机制保证了各个数据服务器器 上的数据块，在基本大方向上都是一致的。可是，因为网络的复杂性，简单的版本信息没法保证具体内容的一致性（由于此版本信息与内容无关，可能会出现版本相 同，但内容不一样的情况）。所以，为了保证数据内容上的一致，必需要依照内容，做出签名。。。
当 客户端向数据服务器追加写入数据包时，每个数据包的数据，都会切分红512字节大小的段，做为签名验证的基本单位，在HDFS中，把这个数据段称为 Chunk，即传输块（注意，在GFS中，Chunk表达的是数据块...）。在每个数据包中，都包含若干个传输块以及每个传输块的签名，当下，这个 签名是根据Java SDK提供的CRC算法算得的，其实就是一个奇偶校验。当数据包传输到流水线的最后一级，数据服务器会对其进行验证（想想，为何 只在最后一级作验证，而不是每级都作...），一旦发现当前的传输块签名与在客户端中的签名不一致，整个数据包的写入被视为无 效，Lease Recover（租约恢复）算法被触发。。。
从 基本原理上看，这个算法很简单，就是取全部数据服务器上此数据块的最小长度看成正确内容的长度，将其余数据服务器上此数据块超出此长度的部分切除。从正确 性上看，此算法无疑是正确的，由于至少有一个数据服务器会发现此错误，并拒绝写入，那么，若是写入了的，都是正确的；从效率上看，此算法也是高效的，由于 它避免了重复的传输和复杂的验证，仅仅是各自删除尾部的一些内容便可。但从具体实现上来看，此算法稍微有些绕，由于，为了下降本已不堪重负的主控服务器的 负担，此算法不是由主控服务器这个大脑发起的，而是经过选举一个数据服务器做为Primary，由Primary发起，经过调用与其余各数据服务器间的 InterDatanodeProtocol协议，最终完成的。具体的算法流程，参见LeaseManager类上面的注释。须要说明的是此算法的触发时 机和发起者。此算法能够由客户端或者是主控服务器发起，当客户端在写入一个数据包失败后，会发起租约恢复。由于，一次写入失败，不管是何种缘由，颇有可能 就会致使流水线上有的服务器写了，有的没写，从而形成不统一。而主控服务器发起的时机，则是在占有租约的客户端超出必定时限没有续签，这说明客户端可能挂 了，在临死前可能干过不利于数据块统一的事情，做为监督者，主控服务器须要发起一场恢复运动，确保一切正确。。。
三、负载均衡
负 载的均衡，是分布式系统中一个永恒的话题，要让你们各尽其力齐心干活，发挥各自独特的优点，不能忙得忙死闲得闲死，影响战斗力。并且，负载均衡也是一个复 杂的问题，什么是均衡，是一个很模糊的概念。好比，在分布式文件系统中，总共三百个数据块，平均分配到十个数据服务器上，就算均衡了么？其实不必定，由于 每个数据块须要若干个备份，各个备份的分布应该充分考虑到机架的位置，同一个机架的服务器间通讯速度更快，而分布在不一样机架则更具备安全性，不会在一棵 树上吊死。。。
在这里说的负载均衡，是宽泛意义上的均衡过程，主要涵盖两个阶段的事务，一个是在任务初始分配的时候尽量合理分配，另外一个是在过后时刻监督及时调整。。。
在 HDFS中，ReplicationTargetChooser类，是负责实现为新分配的数据块寻找婆家的。基本上来讲，数据块的分配工做和备份的数量、 申请的客户端地址（也就是写入者）、已注册的数据服务器位置，密切相关。其算法基本思路是只考量静态位置信息，优先照顾写入者的速度，让多份备份分配到不 同的机架去。具体算法，自行参见源码。此外，HDFS的Balancer类，是为了实现动态的负载调整而存在的。Balancer类派生于Tool类，这 说明，它是以一个独立的进程存在的，能够独立的运行和配置。它运行有NamenodeProtocol和ClientProtocol两个协议，与主控服 务器进行通讯，获取各个数据服务器的负载情况，从而进行调整。主要的调整其实就是一个操做，将一个数据块从一个服务器搬迁到另外一个服务器上。 Balancer会向相关的目标数据服务器发出一个DataTransferProtocol.OP_REPLACE_BLOCK消息，接收到这个消息的 数据服务器，会将数据块写入本地，成功后，通知主控服务器，删除早先的那个数据服务器上的同一块数据块。具体的算法请自行参考源码。。。
四、垃圾回收
对 于垃圾，你们应该耳熟能详了，在分布式文件系统而言，没有利用价值的数据块备份，就是垃圾。在现实生活中，咱们提倡垃圾分类，为了更好的理解分布式文件系 统的垃圾收集，搞个分类也是颇有必要的。基本上，全部的垃圾均可以视为两类，一类是由系统正常逻辑产生的，好比某个文件被删除了，全部相关的数据块都沦为 垃圾了，某个数据块被负载均衡器移动了，原始数据块也不幸成了垃圾了。此类垃圾最大的特色，就是主控服务器是生成垃圾的罪魁祸首，也就是说主控服务器彻底 了解有哪些垃圾须要处理。另外还有一类垃圾，是因为系统的一些异常症状产生的，好比某个数据服务器停机了一段，重启以后发现其上的某个数据块已经在其余服 务器上从新增长了此数据块的备份，它上面的那个备份过时了失去价值了，须要被看成垃圾来处理了。此类垃圾的特色偏偏相反，主控服务器没法直接了解到垃圾状 况，须要曲线救国。。。
在 HDFS中，第一类垃圾的断定天然很容易，在一些正常的逻辑中产生的垃圾，所有被塞进了FSNamesystem的 recentInvalidateSets这个Map中。而第二类垃圾的断定，则放在数据服务器发送其数据块信息来的过程当中，通过与本地信息的比较，能够 判定，此数据服务器上有哪些数据块已经不幸沦为垃圾。一样，这些垃圾也被塞到recentInvalidateSets中去。在与数据服务器进行心跳交流 的过程当中，主控服务器会将它上面有哪些数据块须要删除，数据服务器对这些数据块的态度是，直接物理删除。在GFS的论文中，对如何删除一个数据块有着不一样 的理解，它觉着应该先缓存起来，过几天没人想恢复它了再删除。在HDFS的文档中，则明确表示，在现行的应用场景中，没有须要这个需求的地方，所以，直接 删除就完了。这说明，理念是一切分歧的根本：）。。。
V. 总结整 个分布式文件系统，计算系统，数据库系统的设计理念，基本是一脉相承的。三类服务器、做为单点存在的核心控制服务器、基于日志的恢复机制、基于租约的保持 联系机制、等等，在后续分布式计算系统和分布式数据库中均可以看到相似的影子，在分布式文件系统这里，我详述了这些内容，可能在后续就会默认知道而说的比 较简略了。而刨去这一些，分布式文件系统中最大特色，就是文件块的冗余存储，它直接致使了较为复杂的写入流程。固然，虽然说分布式文件系统在分布式计算和数 据库中都有用到，但若是对其机理没有兴趣，只要把它当成是一个能够在任何机器上使用的文件系统，就不会对其余上层建筑的理解产生障碍。。。