需要整理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（远程过程调用）框架实现机制
-
难点：
- RPC 动态代理+反射机制+Socket通信（代理这里没听明白，为什么要用代理？验证机制是怎么做的？拦截是什么？）
- RPC编程实践的思路梳理（接口与实现类的关系、代理对象的获得，各个方法的形参意义）
- 采用RPC的好处是什么？
- 源码分析
-
复习大纲：
RPC底层原理 （socket、tcp、非hadoop），效果就是好像是本地自己完成的一样，实际上部分中间过程是通过RPC调用服务端的程序实现的
为什么RPC要自己实现RPC框架？优化网络带宽，各节点之间的通信都是通过RPC框架实现的，因为Hadoop本身是一个集群。client与namenode、namenode与datanode、datanode与datanode
实现一个RPC框架 （动态代理+反射机制+Socket通信）
-
RPC框架工作流程：
- 生成动态代理对象proxy（代理调用端socket）
- 通过proxy调用业务方法
- proxy调用的业务方法调用socket的请求方法
- 用socket的send（）方法，向被调用端的socket发送请求，此时工作场景来到了被调用端
- 被调用端的socket接收请求并生成一个被调用端的代理对象
- 被调用端的代理对象调用业务方法
- 被调用端的socket获取代理对象业务方法的返回结果
- 通过socket将结果返回给调用端的socket
- 调用端的socket把结果返回给调用端的业务方法
RPC编程实践（2-07）
注意，RPC编程肯定会分为客户端和服务端，服务端和客户端都有着相同的接口，但是实现类在服务端，客户端这里没有实现类，通过动态代理指向相应的接口，在调用相关的接口方法时，会通过socket把相关的方法参数和信息发送给服务端的socket，服务端socket调用实现类的相应方法，得到返回结果后再返回给客户端，这个过程就是RPC-
采用RPC的好处
集群中可以多个服务器执行相同的程序，提升程序的并发性和扩展性。- 并发性是指同样的服务可以有多个机器来提供，在调用端需要服务时，可以找一个负载空闲的服务器去请求，使系统的并发性得到提高。
- 扩展性同理，若当前系统满负荷了，可以很方便的在集群中增加一个节点，来分担系统的负担
- 如何实现弹性伸缩？即在集群中增加或减少一个节点，在客户端是感应不到的。
-
源码追踪（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（）用来获取文件对应的数据块
-
先从FileSystem.get(conf)的源码看起
- 调用的静态方法get（conf），get（conf）又调的重载方法get（uri，conf）
- get（uri，conf）又调Cache.get(uri,conf) --Cache是FileSystem的一个内部类
- Cache.get(uri,conf)又通过map.get(key)看一看是否能拿到文件系统（map是一个接口，在初始化Cache的过程中已经被HashMap实现了，在Cache里相当于是HashMap<String,FileSystem>），拿到则直接返回，没拿到则会创建一个文件系统createFileSystem()
- createFileSystem()方法中首先获取了一个类对象clazz=getClazz（），然后通过反射机制获取fs实例对象fs=ReflectionUtils.newInstance(clazz,conf)，再对fs初始化fs.initialize()--更具体的说，调用的是DistributedFileSystem实现类的实例方法（FileSystem中也有此方法，本次实例中fs生成的是DistributedFileSystem方法）
- 调用的initialize（）方法中，值得注意的是成员属性dfs=new DFSClient（uri，conf） ，在初始化该成员对象时实现了RPCProxy代理
- 初始化dfs后，dfs里的成员属性namenode是ClientProtocol类型，因为ClientProtocol的作用就是Client用来与namenode通信用的，因此其成员属性干脆直接取名叫了namenode
- 经过一系列其他的操作，最后返回了fs。。。
-
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 合并数据的。
HDFS的读写过程（待整理）
