最近一直都在看徐鹏写的《hadoop 2.X HDFS源码剖析》的第二章关于RPC的部分，表示java这块的编程功底差的实在是太多了，动态代理勉强还算明白，proto buffer、nio还有java的annotation差的实在太多了，好多地方都看得不是很懂。决定暂时放下这块，把整本书看完再多写几篇关于hadoop RPC的文章了。但是还是写一写最近的读书笔记吧。
站在用户的角度思考问题，与客户深入沟通，找到槐荫网站设计与槐荫网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站设计、成都网站建设、
外贸网站建设、企业官网、英文网站、手机端网站、网站推广、
域名注册、网页空间、企业邮箱。业务覆盖槐荫地区。
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
今天二逼节，明天虐狗节，学得又很渣，不开心￣へ￣
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
本文名称：hadoopRPC从入门到暂时放弃-创新互联
当前地址：
http://cdkjz.cn/article/gpgcc.html
