后端分布式系列：分布式存储－HDFS 异常处理与恢复

在前面的文章 《HDFS DataNode 设计实现解析》中我们对文件操作进行了描述，但并未展开讲述其中涉及的异常错误处理与恢复机制。本文将深入探讨 HDFS 文件操作涉及的错误处理与恢复过程。

读异常与恢复

读文件可能发生的异常有两种：

1. 读取过程中 DataNode 挂了
2. 读取到的文件数据损坏

HDFS 的文件块多副本分散存储机制保障了数据存储的可靠性，对于第一种情况 DataNode 挂了只需要失败转移到其他副本所在的 DataNode 继续读取，而对于第二种情况读取到的文件数据块若校验失败可认定为损坏，依然可以转移到读取其他完好的副本，并向 NameNode 汇报该文件 block 损坏，后续处理由 NameNode 通知 DataNode 删除损坏文件 block，并根据完好的副本来复制一份新的文件 block 副本。

因为读文件不涉及数据的改变，所以处理起来相对简单，恢复机制的透明性和易用性都非常好。

写异常与恢复

之前的文章中对写文件的过程做了描述，这个过程中可能发生多种不同的错误异常对应着不同的处理方式。先看看有哪些可能的异常？

异常模式

可能的异常模式如下所列：

• Client 在写入过程中，自己挂了
• Client 在写入过程中，有 DataNode 挂了
• Client 在写入过程中，NameNode 挂了

对于以上所列的异常模式，都有分别对应的恢复模式。

恢复模式

当 Client 在写入过程中，自己挂了。由于 Client 在写文件之前需要向 NameNode 申请该文件的租约（lease），只有持有租约才允许写入，而且租约需要定期续约。所以当 Client 挂了后租约会超时，HDFS 在超时后会释放该文件的租约并关闭该文件，避免文件一直被这个挂掉的 Client 独占导致其他人不能写入。这个过程称为 lease recovery。

在发起 lease recovery 时，若多个文件 block 副本在多个 DataNodes 上处于不一致的状态，首先需要将其恢复到一致长度的状态。这个过程称为 block recovery。 这个过程只能在 lease recovery 过程中发起。

当 Client 在写入过程中，有 DataNode 挂了。写入过程不会立刻终止（如果立刻终止，易用性和可用性都太不友好），取而代之 HDFS 尝试从流水线中摘除挂了的 DataNode 并恢复写入，这个过程称为 pipeline recovery。

当 Client 在写入过程中，NameNode 挂了。这里的前提是已经开始写入了，所以 NameNode 已经完成了对 DataNode 的分配，若一开始 NameNode 就挂了，整个 HDFS 是不可用的所以也无法开始写入。流水线写入过程中，当一个 block 写完后需向 NameNode 报告其状态，这时 NameNode 挂了，状态报告失败，但不影响 DataNode 的流线工作，数据先被保存下来，但最后一步 Client 写完向 NameNode 请求关闭文件时会出错，由于 NameNode 的单点特性，所以无法自动恢复，需人工介入恢复。

上面先简单介绍了对应异常的恢复模式，详细过程后文再描述。在介绍详细恢复过程前，需要了解文件数据状态的概念。因为写文件过程中异常和恢复会对数据状态产生影响，我们知道 HDFS 文件至少由 1 个或多个 block 构成，因此每个 block 都有其相应的状态，由于文件的元数据在 NameNode 中管理而文件数据本身在 DataNode 中管理，为了区分文件 block 分别在 NameNode 和 DataNode 上下文语境中的区别，下面我们会用 replica（副本）特指在 DataNode 中的 block，而 block 则限定为在 NameNode 中的文件块元数据信息。在这个语义限定下 NameNode 中的 block 实际对应 DataNodes 上的多个 replicas，它们分别有不同的数据状态。我们先看看 replica 和 block 分别在 DataNode 和 NameNode 中都存在哪些状态？

Replica 状态

Replica 在 DataNode 中存在的状态列表如下：

• FINALIZED：表明 replica 的写入已经完成，长度已确定，除非该 repli