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