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元数据信息是保存在内存中的，掉电容易丢失，所以他必须相办法保存到磁盘上，怎么保存呢,就是通过序列化机制来实现从内存写到磁盘。这个序列化的镜像文件名称就是fsimage文件。
client -->上出文件(发出请求信息）----> namenode
<-（查询文件有没有，权限够不够，然后要在那个datanode，返回给client。
|
|
|向datanode写信息。
datanode1 datanode2 datanode3
client开始向datanode上写信息了,同时namenode中有个edits文件开始记录信息，不管你写成功（文件名称是什么？存放那台datanode上，快大小），还是失败，它都会记录一条日志数据信息。紧接着namenode中的metadata开始也多了一条数据描述信息。此时写完之后，并没有同步到fsimage（因为他不是及时同步的）假设一个月之前向hdfs上传了2个文件，secondary进过一定的条件会进行合并（有的是edits文件大小，或者超过一定时间尽心合并一次），一个月了，已经合并了很多次了，同步。此时内存中的metadata应该保存了2份描述信息。fsimage里面有2条描述信息（已经同步了），edits文件现在没有了信息，因为一点metadata合并到fsimage信息，edits文件就会被清空。现在client又开始向hdfs上传一个文件，此时，edits中有1个，内存中的metadata变成了3条信息，fsimage还是2条信息，此时metadata和fsimage不同步。当满足一定条件时，secondaryNameNode开始工作了。它通过http协议向namenode下载fsimage和edits文件,namenode生成一个新的editsnew文件(切换)，如果此时有文件来进行读写，它将记录保存在editsnew文件中去，secondary将fsimage和edits文件合并生成新的fsimage,将fsimage回传给namenode,namenode将其就得fsimage和edits文件删除掉，用editsnew文件替换edits文件，这样数据又可以同步了。
分布式文件系统适用于一次写入，多次查询的，不支持并发写情况。小文件不合适。