Lease Recovery

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