一. HDFS存储过程：
1.客户端需要存储一份文件（客户端进行切分），需要查询NN中的元数据。若文件以及存在则拒绝存储。
2.NN返回为客户端的上传申请分配对应的DN存储地址
3.客户端将文件拆分成对应的block后，分别存储在NN指定的DN中。
4.每个block在集群中需要保存三份（hadoop默认三份，可通过修改配置文件调节），客户端blk_01上传到一个DN中，客户端只需要在一个DN中写入文件。DN会将bkl_01复制存储到其他的DN，这个操作是异步进行的。
5.若DN_01向其他的DN_02复制传输的时候发生错误，则DN_01则向NN反馈错误信息，NN则会重新分配一个DN_02地址让DN_01向新的DN_02传输文件。
二. NameNode元数据管理机制
1.NN存储内容需要写入磁盘的fsimage中，防止断电或者宕机的事故。但是磁盘读写速度非常缓慢。
2.NN在内存中存放着最新的数据。此时磁盘中的数据与内存中的数据可能存在不一致的问题。因此为了解决不一致的问题，则引入一个edits_log日志机制，edits_log在磁盘中。
3.客户端提交文件写入操作，NN首先提交到edits_log中，然后返回给客户端写入DN的信息
4.客户端写入一个DN文件后反馈NN完成信息。然后NN将edits_log中的数据更新到内存中。
5.每当edits_log写满时，需要将这一段时间存储新的元数据更新到fsimage文件中。
三. SecondaryNameNode的合并元数据操作
1..edits_log日志文件与fsimage中元数据存储格式不一致。需要进行合并操作需要SecondaryNameNode的帮助。
.2.当NN中的edits存储空间满时，则会通知SN进行checkpoint操作。
3.SN通知NN停止往edits文件中写入数据，防止数据不一致问题。
4.但是在停止edits文件的写入操作时，有新的文件操作日志需要记录，因此这个时候NN就会产生一个新的edits.new文件来存放edits停止写入时的操作信息。
5.SN就会将NN中的fsimage和edits通过http的方式下载下来。
6.然后SN使用自身的CPU资源和内存资源将fsimage和edits进行合并成fsimage.checkpoint文件
7.SN将新的fsimage.checkpoint上传到NN中，NN将原先的fsimage删除后，在重命名fsimage.checkpoint 进行替换，同时将edits删除，将edits.new重命名为edits进行替换。
NameNode和SecondaryNameNode工作机制图解：
