Lease Recovery
今晚的罪恶来源于https://issues.apache.org/jira/browse/HDFS-265,里面再次提到了"Lease Recovery",因为之前在阅读<<Hadoop2.x HDFS源码解析>>时,就对这个Lease Recovery一直不解,对于这个名词,书中包括博客都将其翻译成"租约恢复",为此我费解了好久,为什么client意外中断,NN要恢复它的租约呢?client这一侧大概率已经被kill -9甚至宕机了,怎么能对其进行恢复呢?纳闷了好久,才想明白,应该理解为"租约回收"会更合理一些。而引用中,对于Lease Recovery的描述也不够详尽,博客中对于Lease Recovery的解释大多翻译自这篇引用,这让我陷入了深思。
wait,琢磨了一下时间线,这里是HDFS支持append的design,那么在这之前,应该也存在LeaseRecovery,引用中提到的内容只是对其的修改和补充,那么
没错,更新版本是0.21.0,那么我直接找它之前的最后一个版本就可以了。
于是在这里找到了
因为搭建源码环境耗时且恶心,所以就直接在Linux上"tar + vim + find + grep"了,下载了0.20.2和0.21.0两个版本进行对比
拿append中的一个类文件作为查找条件,果然:
直接看0.20.2中的LeaseRecovery部分,即src/hdfs/org/apache/hadoop/hdfs/server/namenode/LeaseManager.java,根据HDFS 2.x,LeaseManager拥有一个后台线程Monitor,周期性检查是否需要进行某些客户端的租约回收,于是乎
对应于FsNamesystem.java,跟进去
对应于INodeFileUnderConstruction.java,再跟进去
其实看到这里就可以理清大致思路了,在某一个客户端的租约过期时,LeaseManager会遍历被这个客户端持有租约的所有文件,对于每一个文件,LeaseManager会提取出它最后一个Block,对于这个Block的每一个Replica,会采取轮询的方式选取Replica所在的DN作为PrimaryNode,通过响应DN的HeartBeat,NN将命令以DataCommand[]的形式带回给DN,让这个DN充当PrimaryNode去做Block的完整性检查;然后,如FsNamesystem.java中最后的代码,更新LeaseManager相关的list/map等数据结构。
那么下一个问题来了,DN执行DataCommand的代码在哪里?HDFS2.x中,这部分存在于BPServiceActor,但是这时是针对HA和Federation架构的,在0.20.2这个版本还未出现,于是使用原始的方法:
原始的方法有时也很快捷,跟进去
不出意外,应该是这个case,至于后面这个PrimaryNode都做了什么见不得人的事,且听下回分解;至于在支持Append之后,LeaseRecovery以及BlockRecovery干的勾当,且听下下回分解。
顺便提一句,0.20.2版本的代码,相对于2.x和当前最新的3.x,简直是天堂。另附一张更悲伤的图,来自于3.3.3的Release