---

在大规模集群中，节点挂掉的现象是十分常见。当节点挂掉的时候，上面所跑的任务或者发送到这个节点的请求将会失败。按照分布式系统的正常处理方法，它会选择另外的节点进行重新的数据请求。这种重试机制在一定程度上可以解决因为节点意外挂掉导致的请求失败情况，但是这种方式并不是高效的。假设每次的重试代价比较高时，这个时候我们其实更期待能提前检测到这些挂掉的节点。因此我们需要有一套DeadNode节点的监测机制来帮助我们做这样的事情。本文笔者来聊聊关于社区目前在做的关于HDFS DeadNode节点的Detection机制的相关内容。

HDFS DFSClient现有DeadNode监测

---

在HDFS中，读写文件操作是由DFSClient所操作的。DFSClient代表的一个客户端对象，DFSClient可以open多个DFSInputStream去读多个不同的文件。

DFSClient用DFSInputStream读文件时，假若发现有类似节点连接不上的问题，会将连接不上的节点加入到DFSInputStream的本地节点列表内。这样的话，当此DFSInputStream对象在选后续节点时，就会避开那些之前发现的dead node。

但是这里有个问题是，以上的DFSInputStream所监测出的节点都是维护在local的，并不是在DFSClient内全局shared。这会造成一个问题，DFSInputStream1在读文件A时，监测到node1是dead node，然后DFSInputStream2在读文件时，又重复监测到了node1的dead node。这里其实我们看到就存在了重复的dead node的监测。但其实我们可以完全在一个DFSClient下将这些dead node信息进行共享，来提升读文件的效率。一个DFSClient用户是可能长时间open多个DFSInputStream进行操作的。

基于上述的改进，我们本文将讨论的HDFS DeadNode Detection就是将DFSInputStream的local dednode进行共享，设计图如下所示：

DFSClient共享DeadNode的监测和恢复

---

对于一套完整的DeadNode的detection机制来说，里面包括的东西不应只有简单的将local deadnode进行共享就好了，例如还有后续别的问题需要我们去考虑？

• 监测出的deadnode是否真的deadnode，而非只是节点因为maintenance重启了一下导致unservice的状态？
• 对于监测的deadnode，我们如何对这些节点进行状态的update？一个节点不应该永远在deadnode列表内的。

以上两个问题就涉及到完整的一套DeadNode Detection机制了，社区在HDFS-13571: Dead DataNode Detector里设计了一套状态机来跟踪DataNode的liveness状态，状态机如下：

这里简单解释上述状态机转化的含义：

• 首先任何节点初始时默认都是Live状态，意思就是说都是service的状态。
• 当在读文件时发现失败的时候，将节点的状态改为Dead状态，就是加入到dead node list内。
• 当一个DFSInputStream操作在结束关闭的时候，其之前检测出的dead node将会被remove清空掉，同时这些清空掉的节点也将会从shared dead node list中清除出去。因为我们假设当一个DFSInputStream关闭的时候，我们将认为其之前检测出的deadnode是无效的。
• 对于一些可能由于节点短暂重启导致错误被检测的deadnode，我们有额外程序进行周期性的dead node recheck，如果liveness没有问题，则将这些dead node移出表明其已经是live状态了。

以上状态机转化模型就是DFSClient DeadNode Detector所做的主要事情了，这里面的细节实现可参看JIRA：HDFS-14648: mplement DeadNodeDetector basic model。

总的来说，DFSClient的这套提前监测dead node的机制，尤其适用于长时间同时open多个 DFSInputStream进行文件读取的实际应用场景。

引用

---

[1].https://issues.apache.org/jira/browse/HDFS-13571 . Dead DataNode Detector