十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
最近一直都在看徐鹏写的《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许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。