1.前言

Hadoop的RPC主要是通過Java的動態代理（Dynamic Proxy）與反射（Reflect）實現，源代碼在org.apache.hadoop.ipc下，有以下幾個主要類：

Client：RPC服務的客戶端

RPC：實現了一個簡單的RPC模型

Server：服務端的抽象類

RPC.Server：服務端的具體類

VersionedProtocol：所有的使用RPC服務的類都要實現該接口，在創建代理時，用來判斷代理對象是否創建正確。

?

2.Hadoop RPC簡單過程

簡單來說，Hadoop RPC = 動態代理 + 定制好的二進制流。如果不關注細節，從用戶的角度來看，它的結構大致像下圖

????? 遠程的對象擁有固定的接口，這個接口用戶也是可見的，只是真正的實現(Object)只在服務端。用戶如果想使用那個實現的話，他的調用過程如此：先根據那個接口動態代理生成一個代理對象，調用這個代理對象的時候，用戶的調用請求被RPC捕捉到，然后包裝成調用請求，序列化成數據流發送到服務端；服務端從數據流中解析出調用請求，然后根據用戶所希望調用的接口，調用接口真正的實現對象，再把調用結果返回給客戶端。

?

3.Hadoop RPC.java里面有什么

RPC提供了一個簡單的RPC機制，提供以下幾種

靜態方法：

1）***Proxy

waitForProxy、getProxy、stopProxy均是與代理有關的方法，其中wait需要保證namenode啟動正常且連接正常，主要由SecondayNode、Datanode、JobTracker使用。

? 函數原型

1 public static VersionedProtocol getProxy(

2 Class<? extends VersionedProtocol> protocol,

3 long clientVersion,

4 InetSocketAddress addr,

5 UserGroupInformation ticket,

6 Configuration conf,

7 SocketFactory factory) throws IOException;

? 參數說明

1) protocol:RPC Server提供RPC服務的接口。

2) clientVersion:客戶端的版本號。

3) addr:RPC Server地址。

4) ticket

5) conf:配置項。

6) factory:SOCKET工廠。

?

stop方法即停止代理。

get則是一般的獲取代理的方法， 創建代理實例，獲得代理實例的versioncode，再與getProxy方法傳入的versioncode做對比，相同返回代理，不同拋出VersionMismatch異常。

2）getServer

創建并返回一個Server實例，由TaskTracker、JobTracker、NameNode、DataNode使用。

? 函數原型為:

1 public static Server getServer(

2 final Object instance,

3 final String bindAddress,

4 final int port,

5 final int numHandlers,

6 final boolean verbose,

7 Configuration conf) throws IOException;

? 參數說明

1) Instance:RPC Server端對象實例，也就是RPC Client調用的接口實例。

2) bindAddress:RPC Server監聽的IP地址。

3) Port:RPC Server監聽的端口號。

4) numHandlers:處理Call隊列的Handler線程個數。

5) Verbose

6) conf:配置項。

?

3）call

靜態方法，向一系列服務器發送一系列請求，在源碼中沒見到那個類使用該方法。但注釋提到了：Expert，應該是給系統管理員使用的接口。

?

RPC靜態類:

RPC方法僅僅提到了方法的作用，但是具體實現沒說，具體實現就涉及到了RPC的靜態類了，RPC類中有5個靜態內部類，分別為：

RPC.ClientCache：用來緩存Client對象；

RPC.Invocation：每次RPC調用傳的參數實體類，其中Invocation包括了調用方法（Method）和配置文件；

RPC.Invoker：具體的調用類，采用Java的動態代理機制，繼承自InvocationHandler，有remoteId和client成員，id用以標識異步請求對象，client用以調用實現代碼；

RPC.Server：org.apache.hadoop.ipc.Server的具體類，實現了抽象類的call方法，獲得傳入參數的call實例，再獲取method方法，調用即可。用的是反射機制，反射很絕，再沒使用之前，完全不知道該代碼會怎么執行；

RPC. VersionMismatch：版本不匹配異常。

?

類圖結構

?

4.協議接口:

Hadoop是master-slave模型，master只會接受請求并相應，slave在發送請求的同時，也有可能會接受其它請求，其它請求來自slave伙伴或者client。

VersionedProtocol說了，所有要使用RPC服務的類都要實現該接口，我們可以來看一下有哪些接口繼承了該接口。

1）HDFS相關

ClientDatanodeProtocol：client與datanode交互的接口，操作不多，只有一個block恢復的方法。那么，其它數據請求的方法呢？client與datanode主要交互是通過流式的socket實現，源碼在DataXceiver，在這里先不說了；

ClientProtocol：client與Namenode交互的接口，所有控制流的請求均在這里，如：創建文件、刪除文件等；

DatanodeProtocol：Datanode與Namenode交互的接口，如心跳、blockreport等；

NamenodeProtocol：SecondaryNode與Namenode交互的接口。

2）Mapreduce相關

InterDatanodeProtocol：Datanode內部交互的接口，用來更新block的元數據；

InnerTrackerProtocol：TaskTracker與JobTracker交互的接口，功能與DatanodeProtocol相似；

JobSubmissionProtocol：JobClient與JobTracker交互的接口，用來提交Job、獲得Job等與Job相關的操作；

TaskUmbilicalProtocol：Task中子進程與母進程交互的接口，子進程即map、reduce等操作，母進程即TaskTracker，該接口可以回報子進程的運行狀態（詞匯掃盲: umbilical 臍帶的, 關系親密的） 。

3）其它

AdminOperationProtocol：不用用戶操作的接口，提供一些管理操作，如刷新JobTracker的node列表；

RefreshAuthorizationPolicyProtocol，RefreshUserMappingsProtocol：暫不明白。

?

參考url

http://www.wikieno.com/2012/02/hadoop-ipc-rpc/

http://langyu.iteye.com/blog/1183337

?

http://jimmee.iteye.com/blog/1201398

http://jimmee.iteye.com/blog/1201982

http://jimmee.iteye.com/blog/1206201

http://jimmee.iteye.com/blog/1206598

?

轉載于:https://www.cnblogs.com/xuxm2007/archive/2012/06/21/2557726.html

總結

以上是生活随笔為你收集整理的[hadoop源码阅读][6]-org.apache.hadoop.ipc-ipc总体结构和RPC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。