最近一直都在看徐鵬寫的《hadoop 2.X HDFS源碼剖析》的第二章關于RPC的部分，表示java這塊的編程功底差的實在是太多了，動態(tài)代理勉強還算明白，proto buffer、nio還有java的annotation差的實在太多了，好多地方都看得不是很懂。決定暫時放下這塊，把整本書看完再多寫幾篇關于hadoop RPC的文章了。但是還是寫一寫最近的讀書筆記吧。
RPC全名remote procedure call，即遠程調(diào)用，就像生產(chǎn)上經(jīng)常用的dubbo一樣，本地進程通過RPC可以像調(diào)用本地方法一樣調(diào)用遠程的服務。
下面通過介紹一個自認為比較完整的RPC流程，談談自己對hadoop RPC 的理解：
1.首先定義好通信兩端的協(xié)議（protocol），其實就是定義好調(diào)用的接口，這樣調(diào)用者（client）可以知道，應該通過什么樣的函數(shù)，傳遞什么樣的參數(shù)來發(fā)起一個RPC請求，既然是通過網(wǎng)絡傳輸?shù)搅硪粋€jvm，那么就需要進行一次序列化，這里hadoop RPC的實現(xiàn)支持多種序列化，有自身提供的序列化方法跟proto buffer的序列化方法，聽說還可以支持其他的序列化方法，例如namenode 與 客戶端通信的ClientProtocol就是使用的后者；
2.Client端有一個叫做server的ClientNameNodeProtocolTranslatorPB實例，這個類“實現(xiàn)”了ClientProtocol，其實就是將不支持proto buffer的ClientProtocol，轉(zhuǎn)化成了支持這種序列化方式的ClientNamenodeProtocolPB協(xié)，當然這中間涉及到了很多動態(tài)代理，過程十分復雜，現(xiàn)在也看的不是很懂；
3.請求不會這么簡單的發(fā)送出去，從hadoop2.X開始namenode就支持高可用了，所以server對象在實例化的時候就要根據(jù)配置文件，考慮是否支持高可用，其實就是在active namenode失效的時候可以主動failover到standby 的namenode上，向備用的namenode發(fā)送RPC請求；
4.既然請求是序列化過了的，通過socket傳輸，到了Server端，肯定就要有一次反序列化的過程，就是講ClientNamenodeProtocolPB協(xié)議轉(zhuǎn)化為對應的ClientProtocol協(xié)議，然后在調(diào)用真正實現(xiàn)了ClientProtocol接口的NameNodeRPCServer的對應方法進行需要的操作，這里Server端使用了nio的編程方式來處理RPC請求。感覺所謂nio就是有一些監(jiān)聽進程在監(jiān)聽連接事件，然后將PRC請求放入一個隊列，接著又有很多handler處理隊列中的RPC請求，當然為了網(wǎng)絡傳輸，所有handler的執(zhí)行結果都是由一個Responder進程完成的。
以上就是對一次RPC目前能夠做的盡可能詳細的分析了，下面配上一副自己的畫的圖：
基礎差太多，寫的很渣，希望以后能夠來打自己的臉吧！
2017.2.13
今天二逼節(jié)，明天虐狗節(jié)，學得又很渣，不開心￣へ￣
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
