HDFS保证数据一致性与容错机制

数据一致性

  HDFS作为分布式文件系统在分布式环境下如何保证数据一致性。HDFS中，存储的文件将会被分成若干的大小一致的block分布式地存储在不同的机器上，需要NameNode节点来对这些数据进行管理，存储这些block的结点称为DataNode，NameNode是用来管理这些元数据的。

NameNode保证元数据的一致性

  客户端上传文件时，NameNode首先往edits log文件中记录元数据的操作日志。与此同时，NameNode将会在磁盘做一份持久化处理（fsimage文件）：它跟内存中的数据是对应的，如何保证和内存中的数据的一致性？在edits logs满之前对内存和fsimage的数据做同步，合并edits logs和fsimage上的数据，然后edits logs上的数据即可清除。而当edits logs满之后，文件的上传不能中断，所以将会往一个新的文件edits.new上写数据，而老的edits logs的合并操作将由secondNameNode来完成，即所谓的checkpoint操作。
  checkpoint的触发一般由两种限制，一个是edits logs的大小限制，即fs.checkpoint.size配置；一个是指定时间，即fs.checkpoint.period配置。根据规定，大小的限制是优先的，规定edits文件一旦超过阈值，则不管是否达到最大时间间隔，都会强制checkpoint。

  SecondaytNameNode 是 HA（High Available 高可用性）的一个解决方案，但不支持热备，配置即可。SecondaryNameNode执行过程：从NameNode上下载元数据信息（fsimage、edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage。(注：SecondaryNameNode 只存在于Hadoop1.0中，Hadoop2.0以上版本中没有，但在伪分布模式中是有SecondaryNameNode的，在集群模式中是没有SecondaryNameNode的)

SecondaryNameNode 工作流程步骤：

1. SecondaryNameNode 通知NameNode切换edits文件

2. SecondaryNameNode 从NameNode获得fsimage和edits(通过http)

3. SecondaryNameNode 将fsimage载入内存，然后开始合并edits
   （同样合并edits操作是需要满足一定条件才进行的，有两个条件：
   1)fs.checkpoint.period指定两次checkpoint的最大时间间隔，默认3600秒
   2)fs.checkpoint.size规定edits文件的最大值，一旦超过这个值（默认大小是64M）则强制checkpoint，不管是否到达最大时间间隔。）

4. SecondaryNameNode 将新的fsimage发回给NameNode

5. NameNode用新的fsimage替换旧的fsimage

校验和

  HDFS 会对写入的所有数据计算校验和(checksum)，并在读取数据时验证校验和。针对指定字节的数目计算校验和。字节数默认是512 字节，可以通过io.bytes.per.checksum属性设置。通过CRC-32编码后为4字节。
  DataNode 在保存数据前负责验证checksum。client 会把数据和校验和一起发送到一个由多个DataNode 组成的队列中，最后一个DataNode 负责验证checksum。如果验证失败，会抛出一个ChecksumException。客户端需要处理这种异常。客户端从DataNode 读取数据时，也会验证checksum。每个DataNode 都保存了一个验证checksum的日志。每次客户端成功验证一个数据块后，都会告知DataNode ，DataNode 会更新日志。
  每个DataNode 也会在一个后台线程中运行一个DataBlockScanner，定期验证这个 DataNode 上的所有数据块。在用 hadoop fs ge