HDFS-1.x、2.x的RPC接口

HDFS中的主要RPC接口。

架構圖參考前文HDFS1.x、2.x架構圖。

HDFS 1.x

• ClientProtocol：客戶端與名字節點間的接口。客戶端經過這個接口訪問名字節點，操做文件或目錄的元數據信息（如，獲取數據塊位置後，才能繼續與數據節點通訊讀取數據）。另外，還可以管理或查看名字節點的狀態（和由名字節點維護的集羣統計信息）。
• ClientDatanodeProtocol：客戶端與數據節點間的接口。用於客戶端和數據節點進行交互。這個接口用得比較少，客戶端和數據節點間的主要交互是經過流接口進行讀/寫文件數據的操 做；主要在錯誤發生時，客戶端須要數據節點配合進行恢復。另外，或者當客戶端進行本地文件讀優化時，須要經過IPC接口獲取一些信息。
• DatanodeProtocol：數據節點與名字節點間的接口。在HDFS的主從（Master/Slave）結構中，數據節點做爲RPC Client不停的向名字節點發送心跳。心跳請求中攜帶了大量數據節點獲得的正常、異常信息；心跳響應中攜帶了名字節點的指令，指示數據節點進行數據塊的複製、刪除、恢復等。除了心跳，數據節點的註冊、管道寫過程當中的等多項操做也經過該節點完成。
• InterDatanodeProtocol：數據節點與數據節點間的接口。數據節點經過這個接口，和其餘數據節點進行通訊，主要用於數據塊的恢復等。
• NamenodeProtocol：第二名字節點與名字節點間的接口。第二名字節點會不停地獲取名字節點上某一個時間點的命名空間鏡像（fsimage）和鏡像的變化日誌（editlog），而後合併獲得新的鏡像，並將該結果同步回名字節點。

HDFS 2.x

若是不開啓HA，那麼HDFS 2.x用到的主要RPC接口與1.x基本相同。

若是開啓了HA，那麼檢查點工做就再不須要第二名字節點的配合，也就不須要NamenodeProtocol了。

開啓HA後的檢查點工做原理

在1.x中已經介紹了未開啓HA時的檢查點工做原理：fsimage與editlog僅保存在惟一的名字節點上，第二名字節點按期合併獲得新的鏡像，並同步回名字節點。

在2.x的HA機制中，引入JournalNode（至少3個，最好是奇數）在active於standby節點間同步fsimage與editlog：active節點實時將editlog同步到JournalNode集羣中（保證至少n - (n-/1)/2個節點成功）；standby節點實時從JournalNode集羣中同步回editlog。能夠認爲standby上的命名空間鏡像與active上是徹底一致的，所以，standby只須要按期檢查editlog是否有變化，並相應在本地合併獲得新的鏡像。而後經過HTTP接口同步回active節點。

---

本文連接：HDFS-1.x、2.x的RPC接口
做者：猴子007
出處：monkeysayhi.github.io
本文基於 知識共享署名-相同方式共享 4.0 國際許可協議發佈，歡迎轉載，演繹或用於商業目的，可是必須保留本文的署名及連接。