Hadoop中的RPC实现(概述)

释放双眼,带上耳机,听听看~!
  • Hadoop作为一个存储与服务的基础性平台,同时它的内部有采用了master/slave架构,那么其内部通信和与客户端的交互就是必不可少的了。Hadoop在实现时抛弃了JDK自带的一个RPC实现——RMI,而自己基于IPC模型实现了一个高效的轻量级RPC。

链接地址

整体结构

    在IPC包中,最重要的3个类是ServerC,lient和RPC,它们具有层次化的结构

  1.    1.RPC类是对Server、Client的具体化。在RPC类中规定,客户程序发出请求调用时,参数类型必须是Invocation;从服务器返回的值类型必须是ObjectWritable。为了加强理解,可以查看测试类TestIPC。在那里,规定的参数类型与返回值类型都是LongWritable。
  2.    2.RPC类是对Server、Client的包装,简化用户的使用。如果一个类需充当服务器,只需通过RPC类的静态方法getServer获得Server实例,然后start。同时此类提供协议接口的实现。如果一个类充当客户端,可以通过getProxy或者waitForProxy获得一个实现了协议接口的proxy object,与服务器端交互。为了加强理解,可以查看测试类TestRPC,在那里,实现的协议接口为TestProtocol。

Server类

  1.     1.启动Listener进程。如果收到需要建立连接的请求,将建立连接,然后在上面捕获读操作的命令。收到命令之后,将把解析客户端发过来信息的工作委派给Connection。Connection把信息封装到Call对象中,放入队列中,待Handler处理。
  2.     2.启动指定数目的Handler线程,处理客户端对指定方法调用的请求,然后把结果返回给客户端。

Client类

  1.     1.用Call封装好调用信息,然后借助从连接池中取出的Connection向服务器端发送,等待结果。如果到指定服务器的Connection不存在,将马上建立。Connection线程读取服务器方法调用的返回信息。完成之后,通知主线程。

客户端C要发起向服务端S的关于方法M调用

    1. C首先创建一个通向S的连接getConnection,然后将此次调用放入CallList里,这样客户端就可以同时发生很多调用,每个调用用ID来识别。
2. 发送调用参数。调用参数是Client的调用方(比如NameNode,DataNode等)指定的,一般就是一个Invocation对象,里面包含要调用的方法和参数。了解JAVA动态代理类
java.lang.reflect.Proxy会对这里的理解有很大帮助。
3. 等待调用结果.Client.Connection是个线程类,启动了之后唯一做的时候就是等待调用结果
对于服务器端,其有一个方法start指定了启动服务器开始监听,这个start被四个类调用,分别是TaskTracker.initialize,Namenode.initialize,Jobtracker.offerService,Datanode.startDatanode显然,任何两者之间的通信都是考这个client-server模型实现的。
server start后,干了三件事
1. 启动listen,监听客户端Call
2. 启动response,随时准备将处理结果发回client
3. 启动10个handler,处理具体的请求。
这里必须对
java NIO
机制了解,才能看的明白。
当客户端调用来到的时候
1. listen首先将调用doaccept将Connection附加给selectionkey,然后调用doread添加,doread会调用Connecton的方法将调用添加到调用列表,该列表是BlockingQueue,其保持列表先进先出的特性而且支持同步
2. listen将call添加到calllist后,handler因为一直在检测calllist,于是其立刻开始处理,处理完毕后,其将结果保存在call对象中,然后调用response开始向客户端写。这里hadler调用的call只是一个未实现的方法,具体实现在RPC.Server中,这点需要注意。
3. Response也监视responselist,如果responselist中某个call需要将结果写入客户端,就写出,当某个call的结果被发送完毕,从responselist中删除该call对象。
这里有个细节:handler完成call之后就开始向客户端写call结果,但是结果可能太多,无法通过一次性发送完毕,而发送之后还要等待client接受完毕才能再发,如果现在handler在那里等待客户端接受完毕,然后再发,效率不高。解决办法是handler处理完毕之后,只向client发送一次处理结果。如果这一次将处理结果发送完毕,接下来就没有response的事情了,如果没有发送完毕,接下来response负责将剩下的处理结果发送给客户端。这样handler的并发量会大一些。
服务器实现中大量利用监视队列,比如handler就直观坚持calllist,一旦发现数据就开始处理,而response就监视responselist,发现数据需要发送就开始发送。

给TA打赏
共{{data.count}}人
人已打赏
安全经验

google adsense作弊及反作弊技术分析

2021-10-11 16:36:11

安全经验

安全咨询服务

2022-1-12 14:11:49

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索