HDFS中FileSystem的源码分析

2019-08-05 本文已影响0人 HamletSunS

需要整理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<String,FileSystem>），拿到则直接返回，没拿到则会创建一个文件系统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的读写过程（待整理）

HDFS中FileSystem的源码分析

FileSystem设计思想

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

猜你喜欢

热点阅读