Hadoop二次开发必备，Hadoop源码分析（九）

我们开始对租约Lease进行分析，下面是类图。Lease可以认为是一个文件写锁，当客户端需要写文件的时候，它需要申请一个Lease，NameNode负责记录那个文件上有Lease，Lease的客户是谁，超时时间（分布式处理的一种常用技术）等，所有这些工作由下面3个类完成。至于租约过期NameNode需要采取什么动作，并不是这部分code要完成的功能。



LeaseManager（左）管理着系统中的所有Lease（右），同时，LeaseManager有一个线程Monitor，用于检查是否有Lease到期。一个租约由一个holder（客户端名），lastUpdate（上次更新时间）和paths（该客户端操作的文件集合）构成。了解了这些属性，相关的方法就很好理解了。LeaseManager的方法也就很好理解，就是对Lease进行操作。注意，LeaseManager的addLease并没有检查文件上是否已经有Lease，这个是由LeaseManager的调用者来保证的，这使LeaseManager跟简单。内部类Monitor通过对Lease的最后跟新时间来检测Lease是否过期，如果过期，简单调用FSNamesystem的internalReleaseLease方法。这部分的代码比我想象的简单，主要是大部分的一致性逻辑都存在于LeaseManager的使用者。在开始分析FSNamesystem.java这个4.5k多行的庞然大物之前，我们继续来扫除外围的障碍。下面是关于访问控制的一些类：


Hadoop文件保护采用的UNIX的机制，文件用户分文件属主、文件组和其他用户，权限读，写和执行（FsAction中抽象了所有组合）。
我们先分析包org.apache.hadoop.fs.permission的几个类吧。FsAction抽象了操作权限，FsPermission记录了某文件/路径的允许情况，分文件属主、文件组和其他用户，同时提供了一系列的转换方法，applyUMask用于去掉某些权限，如某些操作需要去掉文件的写权限，那么可以通过该方法，生成对应的去掉写权限的FsPermission对象。PermissionStatus用于描述一个文件的文件属主、文件组和它的FsPermission。

INode在保存PermissionStatus时，用了不同的方法，它用一个long变量，和SerialNumberManager配合，保存了PermissionStatus的所有信息。

SerialNumberManager保存了文件主和文件主号，用户组和用户组号的对应关系。注意，在持久化信息FSImage中，不保存文件主号和用户组号，它们只是SerialNumberManager分配的，只保存在内存的信息。通过SerialNumberManager得到某文件主的文件主号时，如果找不到文件主号，会往对应关系中添加一条记录。

INode的long变量作为一个位串，分组保存了FsPermission（MODE），文件主号（USER）和用户组号（GROUP）。

PermissionChecker用于权限检查。


---------------------------------------------------------------------------------------------------------------------------------------------------


下面我们来分析FSDirectory。其实分析FSDirectory最好的地方，应该是介绍完INode*以后，FSDirectory在INode*的基础上，保存了HDFS的文件目录状态。系统加载FSImage时，FSImage会在FSDirectory对象上重建文件目录状态，HDFS文件目录状态的变化，也由FSDirectory写日志，同时，它保存了文件名à数据块的映射关系。FSDirectory只有很少的成员变量，如下：  finalFSNamesystem namesystem;
  finalINodeDirectoryWithQuota rootDir;
  FSImage fsImage;
  booleanready = false;其中，namesystem，fsImage是指向FSNamesystem对象和FSImage对象的引用，rootDir是文件系统的根，ready初值为false，当系统成功加载FSImage以后，ready会变成true，FSDirectory的使用者就可以调用其它FSDirectory功能了。FSDirectory中剩下的，就是一堆的方法（我们不讨论和MBean相关的类，方法和过程）。


loadFSImage用于加载目录树结构，它会去调用FSImage的方法，完成持久化信息的导入以后，它会把成员变量ready置为true。系统调用loadFSImage是在FSNamesystem.java的initialize方法，那是系统初始化重要的一步。addFile用于创建文件或追加数据时创建INodeFileUnderConstruction，下图是它的Call Hierachy图：


addFile首先会试图在系统中创建到文件的路径，如果文件为/home/hadoop/Hadoop.tar，addFile会调用mkdirs（创建路径为/home/hadoop，这也会涉及到一系列方法），保证文件路径存在，然后创建INodeFileUnderConstruction节点，并把该节点加到目录树中（通过addNode，也是需要调用一系列方法），如果成功，就写操作日志（logOpenFile）。

unprotectedAddFile也用于在系统中创建一个目录或文件（非UnderConstruction），如果是文件，还会建立对应的block。FSDirectory中还有好几个unprotected*方法，它们不检查成员变量ready，不写日志，它们大量用于loadFSEdits中（这个时候ready当然是false，而且因为正在恢复日志，也不需要写日志）。

addToParent添加一个INode到目录树中，并返回它的上一级目录，它的实现和unprotectedAddFile是类似的。

persistBlocks比较有意思，用于往日志里记录某inode的block信息，其实并没有一个对应于persistBlocks的写日志方法，它用的是logOpenFile。这个大家可以去检查一下logOpenFile记录的信息。closeFile对应了logCloseFile。

addBlock和removeBlock对应，用于添加/删除数据块信息，同时它们还需要更新FSNamesystem.java中对应的信息。

unprotectedRenameTo和renameTo实现了UNIX的mv命令，主要的功能都在unprotectedRenameTo中完成，复杂的地方在于对各种各样情况的讨论。

setReplication和unprotectedSetReplication用于更新数据块的副本数，很简单的方法，注意，改变产生的对数据块的删除/复制是在FSNamesystem.java中实现。

setPermission，unprotectedSetPermission，setOwner和unprotectedSetOwner都是简单的方法。

Delete和unprotectedDelete又是一对方法，删除如果需要删除数据块，将通过FSNamesystem的removePathAndBlocks进行。……(后续的方法和前面介绍的，都比较类似，都是一些过程性的东西，就不再讨论了)

下一篇

Hadoop二次开发必备，Hadoop源码分析（十）

下一篇

Hadoop二次开发必备，Hadoop源码分析（八）