HDFS中FileSystem的源码分析

需要整理HDFS的读写过程

FileSystem设计思想

• FileSystem本身是一个抽象类，有多个子类，根据配置文件中配置项的不同会有不同的子类实现。可以认为FileSystem屏蔽了底层不同文件系统的细节实现，对外暴露的是统一的接口，方便其他函数的调用。

FileSystem fs = null;

    public void init() throws Exception{
        
        //读取classpath下的xxx-site.xml 配置文件，并解析其内容，封装到conf对象中
        Configuration conf = new Configuration();
        
        //也可以在代码中对conf中的配置信息进行手动设置，会覆盖掉配置文件中的读取的值
        conf.set("fs.defaultFS", "hdfs://weekend110:9000/");
        
        //根据配置信息，去获取一个具体文件系统的客户端操作实例对象
        fs = FileSystem.get(new URI("hdfs://weekend110:9000/"),conf,"hadoop");
        
        
    }

• 可以看出，fs的示例是FileSystem.get(conf)来得到的，具体的实现子类是根据conf的配置文件中的配置项决定的。
• FileSystem的子类包括DistributedFileSystem、FTPFileSystem、RawLocalFileSystem等多个不同的文件系统

Hadoop的RPC（远程过程调用）框架实现机制

• 难点：

  1. RPC 动态代理+反射机制+Socket通信（代理这里没听明白，为什么要用代理？验证机制是怎么做的？拦截是什么？）
  2. RPC编程实践的思路梳理（接口与实现类的关系、代理对象的获得，各个方法的形参意义）
  3. 采用RPC的好处是什么？
  4. 源码分析

• 复习大纲：

  1. RPC底层原理 （socket、tcp、非hadoop），效果就是好像是本地自己完成的一样，实际上部分中间过程是通过RPC调用服务端的程序实现的

  2. 为什么RPC要自己实现RPC框架？优化网络带宽，各节点之间的通信都是通过RPC框架实现的，因为Hadoop本身是一个集群。client与namenode、namenode与datanode、datanode与datanode

  3. 实现一个RPC框架 （动态代理+反射机制+Socket通信）

  4. RPC框架工作流程：

     1. 生成动态代理对象proxy（代理调用端socket）
     2. 通过proxy调用业务方法
     3. proxy调用的业务方法调用socket的请求方法
     4. 用socket的send（）方法，向被调用端的socket发送请求，此时工作场景来到了被调用端
     5. 被调用端的socket接收请求并生成一个被调用端的代理对象
     6. 被调用端的代理对象调用业务方法
     7. 被调用端的socket获取代理对象业务方法的返回结果
     8. 通过socket将结果返回给调用端的socket
     9. 调用端的socket把结果返回给调用端的业务方法

  5. RPC编程实践（2-07）
     注意，RPC编程肯定会分为客户端和服务端，服务端和客户端都有着相同的接口，但是实现类在服务端，客户端这里没有实现类，通过动态代理指向相应的接口，在调用相关的接口方法时，会通过socket把相关的方法参数和信息发送给服务端的socket，服务端socket调用实现类的相应方法，得到返回结果后再返回给客户端，这个过程就是RPC

  6. 采用RPC的好处
     集群中可以多个服务器执行相同的程序，提升程序的并发性和扩展性。

     • 并发性是指同样的服务可以有多个机器来提供，在调用端需要服务时，可以找一个负载空闲的服务器去请求，使系统的并发性得到提高。
     • 扩展性同理，若当前系统满负荷了，可以很方便的在集群中增加一个节点，来分担系统的负担
     • 如何实现弹性伸缩？即在集群中增加或减少一个节点，在客户端是感应不到的。

  7. 源码追踪（2-8，2-9）
     主要思路：1.抓住代理对象RPCProxy是在fs中的哪一步获取的，之后的方法都是由proxy对象调用相应方法实现的2.看一看proxy实现了哪些接口，与namenode和datanode通信时分别用的哪些方法、实现的哪些接口

     • FileSystem通过get配置文件得到对应的文件系统的实现类并赋值给fs（多种文件系统中的一种，这里假设对应的是DistributedFileSystem）
     • fs通过open打开一个DFSInputStream is
     • DFSInputStream 是用来读取数据的，元数据不在本地而在namenode上，因此肯定用到了RPC框架，既然用RPC框架，那么本地就需要一个代理RPCProxy（在fs中）
     • client与namenode想要通信，那么RPCProxy必须与namenode使用同一个接口，这样才能把方法对应起来。这个接口在hadoop中的名字是ClientProtocal，用来处理client与namenode之间的通信
     • ClientProtocal接口中有一个重要的方法是getBlockLocation（）用来获取文件对应的数据块

  8. 先从FileSystem.get(conf)的源码看起

     1. 调用的静态方法get（conf），get（conf）又调的重载方法get（uri，conf）
     2. get（uri，conf）又调Cache.get(uri,conf) --Cache是FileSystem的一个内部类
     3. Cache.get(uri,conf)又通过map.get(key)看一看是否能拿到文件系统（map是一个接口，在初始化Cache的过程中已经被HashMap实现了，在Cache里相当于是HashMap），拿到则直接返回，没拿到则会创建一个文件系统createFileSystem()
     4. createFileSystem()方法中首先获取了一个类对象clazz=getClazz（），然后通过反射机制获取fs实例对象fs=ReflectionUtils.newInstance(clazz,conf)，再对fs初始化fs.initialize()--更具体的说，调用的是DistributedFileSystem实现类的实例方法（FileSystem中也有此方法，本次实例中fs生成的是DistributedFileSystem方法）
     5. 调用的initialize（）方法中，值得注意的是成员属性dfs=new DFSClient（uri，conf） ，在初始化该成员对象时实现了RPCProxy代理
     6. 初始化dfs后，dfs里的成员属性namenode是ClientProtocol类型，因为ClientProtocol的作用就是Client用来与namenode通信用的，因此其成员属性干脆直接取名叫了namenode
     7. 经过一系列其他的操作，最后返回了fs。。。

  9. NameNode 实现了ClientProtocal、DatanodeProtocal、NamenodeProtocal 等接口，换句话说，namenode再RPC框架中扮演的是服务端的角色

     • ClientProtocal接口是供客户端调用的，包括了许多对HDFS的操作，例如create、delete、mkdirs、rename 等
     • DatanodeProtocol这个接口是供DataNode 调用的。DataNode 调用该接口中的方法向NameNode 报告
       本节点的状态和block 信息。NameNode 不能向DataNode 发送消息， 只能通过该接口中方法的返回值向DataNode 传递消息
     • NamenodeProtocol这个接口是供ScondaryNameNode 调用的。SecondaryNameNode 是专门做NameNode 中edits 文件向fsimage 合并数据的。

  10. HDFS的读写过程（待整理）