1. 程式人生 > >Hadoop RPC機制-原理篇

Hadoop RPC機制-原理篇

       RPC是Hadoop的基礎元件,提供分散式環境下的物件呼叫功能。之前用了三天時間分析與測試RPC,目的是想弄清楚它的整個執行機制。
       概括的說,RPC採用客戶機/伺服器模式。請求程式就是一個客戶機,而服務提供程式就是一個伺服器。首先,客戶機呼叫程序傳送一個有程序引數的呼叫資訊到服務程序,然後等待應答資訊。在伺服器端,程序保持睡眠狀態直到呼叫資訊的到達為止。當一個呼叫資訊到達,伺服器獲得程序引數,計算結果,傳送答覆資訊,然後等待下一個呼叫資訊,最後,客戶端呼叫程序接收答覆資訊,獲得程序結果,然後呼叫執行繼續進行。

前言:
       我們一般情況下通過客戶端呼叫服務,都是現在同一個JVM中,通過在本地JVM中建立一個服務物件,進而通過呼叫該物件呼叫其內部的相關服務方法。
       當客戶端與服務不在同一個JVM中,一般情況下服務被單獨放在一臺伺服器上執行,然後將服務釋出為一個webservice,此時客戶端通過UDDI找到WSDL描述文件後,可以通過SOAP呼叫你建立的Web服務中的一個或多個操作。但SOAP協議冗餘較多,佔用網路頻寬大,並不適合分散式機器之間頻繁的通訊操作。

        RPC,專業名稱為遠端過程呼叫。RPC協議比SOAP更加精簡,通過RPC我們可以從網路上的計算機請求服務,而不需要了解底層網路協議。Hadoop底層的互動都是通過RPC進行的。例如Client、DataNode、NameNode之間的通訊全靠它。我們操作HDFS的時候,使用的是FileSystem類,它的內部有個DFSClient物件,這個物件負責與NameNode打交道。在執行時,DFSClient在本地建立一個NameNode的代理,然後就操作這個代理,這個代理就會通過網路,遠端呼叫到NameNode的方法,返回相應的值。

RPC模式
       在java的網路程式設計中:當客戶端傳送一個位元組給服務端時,服務端必須也要有一個讀位元組的方法在阻塞等待;反之亦然。這種我把它稱為底層的通訊協議。於是我們就可以想像一下,如果不使用RPC,那麼在分散式呼叫中流程應該是樣:伺服器端先建立ServerSocket,在指定的ip地址和埠上監聽,客戶端建立到遠端連線的Socket,待socket套接字完畢,我們可以從套接字拿到輸入輸出流InputStream,OutputStream。接著客戶端就可以往輸出流寫序列化的引數,伺服器端將讀到的輸入流中引數流進行反序列化成程式支援的型別,然後將處理的結果再序列化到輸出流,傳送給客戶端。RPC就是基於此,將Socket程式進行了封裝,並且定義了許多介面,將介面和介面中的方法稱為協議,客戶端和服務端只要實現這些介面中的方法就可以進行通訊了。

工作原理

執行時,一次客戶端對服務端的RPC呼叫,其內部操作大致有如下十步:



       當然,這只是RPC實現的一個非常基礎性的簡單原理,便於理解。真實的RPC框架也是基於此原理,只不過在此基礎上增加了許多優化和容錯的功能!

       基於以上工作原理,我在Github上上傳了一個利用Hadoop RPC框架進行服務呼叫的小程式,結合起來可以更深刻的理解它的原理和應用。

下載地址:https://github.com/Jerry-Fu/HadoopRpcApplication/