,,,,,,,,最近一直都在看徐鹏写的《hadoop 2。X HDFS源码剖析》的第二章关于RPC的部分,表示java这块的编程功底差的实在是太多了,动态代理勉强还算明白,原型缓冲区,nio还有java的注释差的实在太多了,好多地方都看得不是很懂。决定暂时放下这块,把整本书看完再多写几篇关于hadoop RPC的文章了。但是还是写一写最近的读书笔记吧。
,,RPC全名远程过程调用,即远程调用,就像生产上经常用的达博一样,本地进程通过RPC可以像调用本地方法一样调用远程的服务只,,,
,,,,下面通过介绍一个自认为比较完整的RPC流程,谈谈自己对hadoop RPC的理解:
,,,,,,,, 1。首先定义好通信两端的协议(协议),其实就是定义好调用的接口,这样调用者(客户端)可以知道,应该通过什么样的函数,传递什么样的参数来发起一个RPC请求,既然是通过网络传输到另一个jvm,那么就需要进行一次序列化,这里hadoop RPC的实现支持多种序列化,有自身提供的序列化方法跟原型缓冲区的序列化方法,听说还可以支持其他的序列化方法,例如namenode与客户端通信的ClientProtocol就是使用的后者;
,,,,,,,, 2。客户端有一个叫做服务器的ClientNameNodeProtocolTranslatorPB实例,这个类“实现”了ClientProtocol,其实就是将不支持原型缓冲区的ClientProtocol,转化成了支持这种序列化方式的ClientNamenodeProtocolPB协,当然这中间涉及到了很多动态代理,过程十分复杂,现在也看的不是很懂;
,,,,,,,, 3。请求不会这么简单的发送出去,从hadoop2。X开始namenode就支持高可用了,所以服务器对象在实例化的时候就要根据配置文件,考虑是否支持高可用,其实就是在活跃namenode失效的时候可以主动故障转移到备用的namenode上,向备用的namenode发送RPC请求;
,,,,,,4.既然请求是序列化过了的，通过socket传输，到了Server端，肯定就要有一次反序列化的过程，就是讲ClientNamenodeProtocolPB协议转化为对应的ClientProtocol协议，然后在调用真正实现了ClientProtocol接口的NameNodeRPCServer的对应方法进行需要的操作，这里Server端使用了nio的编程方式来处理RPC请求。感觉所谓nio就是有一些监听进程在监听连接事件，然后将PRC请求放入一个队列，接着又有很多handler处理队列中的RPC请求，当然为了网络传输，所有handler的执行结果都是由一个Responder进程完成的。
以上就是对一次RPC目前能够做的尽可能详细的分析了，下面配上一副自己的画的图：
基础差太多，写的很渣，希望以后能够来打自己的脸吧！
2017.2.13
今天二逼节，明天虐狗节，学得又很渣，不开心￣へ￣
