hdfs（hadoop分布式系统）设计需要考虑的问题？

第一个就是数据是如何存储吗（数据的物理存储）

每台机器上都有个datanode节点。这个节点是用来存储数据的。

hdfs对一个大的文件进行分块，每个版本对每一个分块大小可能不尽相同。Hadoop 1版本默认是64M，

假设80M东西，就被分成64M和16M东西。那么他是按照这样的格式来划分的。每个快是分散存储的。可能这个快64M是在这个datonode，另外一块16是在另外一台datanode上。

第二个就是数据的安全（数据的丢失）

分布式系统通常都有备份，一个80M东西，可能64M东西有好几份，16M的东西有好几份。它们备份东西，几个DataNode节点可以相互通信，相互备份，然后告诉NameNode有几份,即使某台datanode，坏了，数据依然能够有备份。

第三个就是数据的访问（客户端和服务器端的通信）

客户端是如何和分布式系统之间进行通信的。

在开启分布式服务的是后续，会有3个进程，一个进程是DataNode,一个是NameNode,另外一个是Secondarynamede

    client        --------步骤1(RPC通信)----->Namenode



                   DataNode1               DataNode2                   DataNode3

服务器要去读取文件，首先他和NameNode通信，NameNode里面包含元数据。它进行相应的检查，然后它告诉客户端去找那个DataNode，通过流的方式来读写，读完之后，关闭流。

SecondaryNameNode是一个冷备份。它是一个对Namenode进行备份的东西，Namenode崩溃了，整个分布式系统就完了，必须有补救措施。

SecondaryNameNode是怎么样补救NameNODE？

首先namenode元数据信息是保存在内存中的，掉电容易丢失，所以他必须相办法保存到磁盘上，怎么保存呢,就是通过序列化机制来实现从内存写到磁盘。这个序列化的镜像文件名称就是fsp_w_picpath文件。


client       -->上出文件(发出请求信息）----> namenode

                <-（查询文件有没有，权限够不够，然后要在那个datanode，返回给client。



|

|

|向datanode写信息。


                datanode1      datanode2     datanode3


client开始向datanode上写信息了,同时namenode中有个edits文件开始记录信息，不管你写成功（文件名称是什么？存放那台datanode上，快大小），还是失败，它都会记录一条日志数据信息。紧接着namenode中的metadata开始也多了一条数据描述信息。此时写完之后，并没有同步到fsp_w_picpath（因为他不是及时同步的）假设一个月之前向hdfs上传了2个文件，secondary进过一定的条件会进行合并（有的是edits文件大小，或者超过一定时间尽心合并一次），一个月了，已经合并了很多次了，同步。此时内存中的metadata应该保存了2份描述信息。fsp_w_picpath里面有2条描述信息（已经同步了），edits文件现在没有了信息，因为一点metadata合并到fsp_w_picpath信息，edits文件就会被清空。现在client又开始向hdfs上传一个文件，此时，edits中有1个，内存中的metadata变成了3条信息，fsp_w_picpath还是2条信息，此时metadata和fsp_w_picpath不同步。当满足一定条件时，secondaryNameNode开始工作了。它通过http协议向namenode下载fsp_w_picpath和edits文件,namenode生成一个新的editsnew文件(切换)，如果此时有文件来进行读写，它将记录保存在editsnew文件中去，secondary将fsp_w_picpath和edits文件合并生成新的fsp_w_picpath,将fsp_w_picpath回传给namenode,namenode将其就得fsp_w_picpath和edits文件删除掉，用editsnew文件替换edits文件，这样数据又可以同步了。

分布式文件系统适用于一次写入，多次查询的，不支持并发写情况。小文件不合适。