百度權(quán)重查詢 站長交易 友情鏈接交換 網(wǎng)站監(jiān)控 服務(wù)器監(jiān)控 seo監(jiān)控

好近開始看 Hadoop 的一些源碼，睜開hadoop的源碼包，各個組件分得比較清楚，于是開始看一下 IPC 的一些源碼。

IPC模塊，也就是進程間通信模塊，假如是在不同的機器上，那就可以理解為 RPC 了，也就是遠程調(diào)用。事實上， hadoop 中的 IPC 也就是基于 RPC 實現(xiàn)的。

使用 sloccount 統(tǒng)計一下 ipc 包中代碼的行數(shù)，一共是 2884 行。也就是說，IPC 作為hadoop的基礎(chǔ)組件，僅僅用了不到3000行的代碼，就完成得穩(wěn)定且富有用率。

IPC 中的關(guān)鍵類關(guān)系：

對用戶而言，可以直接使用的就是綠色的類。

通過 RPC 這個門面：

客戶端可以創(chuàng)建響應(yīng)的 proxy，接著就可以進行遠程調(diào)用。

而服務(wù)提供者則可以創(chuàng)建響應(yīng)的 server，并進行響應(yīng)的生命周期管理（start、stop），從而提供服務(wù)。

序列化

從上圖也可以看出，client 和 server 的交互，是通過網(wǎng)絡(luò) connection， 而走網(wǎng)絡(luò)的調(diào)用，是需要走序列化/反序列話的過程的。

這個過程， IPC 使用了 Hadoop 的自己的序列化機制，一切都在 Writable 接口中，只要給定 writable 的 DataOutput 和 DataInput，就可以讓 Writable 自己實現(xiàn)序列化。

一些問題和思考

• client 是單例的嗎 —— 可以理解為是，但其實不一定。可以跟蹤 getProxy 的代碼，雖然每次都會新建一個代理對象，但底層的 Client 照舊和 SocketFactory 對應(yīng)的。一般默認的，都是使用默認的 SocketFactory， 但假如你設(shè)置了 "hadoop.rpc.socket.factory.class.default" ，則會有新的Client與你自定義的 SocketFactory 對應(yīng)。這時候， client 就不是單例的。

• client 與統(tǒng)一個 server 有幾個連接 —— 一個 client與一個 server 只有一個連接，具體可以看生成的代理中，有一個 remoteId, 這個 remoteId 是和 client關(guān)聯(lián)的，client 進行調(diào)用的使用，會將此 remoteId 作為一個 connectionId。因此，一般一個 client 是一個連接。

• 假如 client 是一個連接，那么對此 client 的調(diào)用，不都是串行的嗎？ —— 看你怎么理解了，在用戶層面，也就是 client 調(diào)用的方法，是可以并發(fā)的。client 底層是使用一個連接來進可能的完成吞吐量。每個 request 和 response 都會有一個 id 關(guān)聯(lián)起來。因此一個連接上可以跑滿請求和響應(yīng)。

• 因為網(wǎng)絡(luò)問題，client調(diào)用服務(wù)失敗后，有重試機制嗎 —— 在IPC中沒有看到call的重試，需要上層去保證了。但是后面的調(diào)用會重新建立連接。

• server 是單例的嗎 —— 不一定。假如你只 getServer 一次的話。創(chuàng)建一個 server 的代價是特別很是重的。通過上圖你也可以知道，他需要有一個線程 （Listener）來 accept socket，同時需要一些 Reader線程 來進行 socket 的 read，還有一個 Responder 來進行 socket 的 write，另外，還有若干個 handler線程 來進行營業(yè)處理。因此，假如可以削減 server 的個數(shù)，就應(yīng)該削減 server 個數(shù)。

• 暴露出的服務(wù)是否應(yīng)該是線程安全的 —— 是的，一定要線程安全。server 底層是通過 nio 進行 socket 操作的，因此雖然只有一個線程負責(zé) accept，但是能夠支撐許多的client連接。這些連接在到達 server 端之后，很有可能就會并發(fā)執(zhí)行統(tǒng)一方法（假如你的營業(yè)handler不止一個的話）

• 一個 server 要消費多少線程資源？ —— 讓我們來算一下，一個 Listener 線程，若干個 Reader 線程（默認1個），若干個 Handler 線程（在 getServer 的時候指定，一般1 - 10個），一個 Responder 線程。假如都按照默認值來計算的話。好少需要 1 + 1 + 1 + 1 = 4 個線程。也許，不應(yīng)該算多，假如請求量不大的話，這些線程應(yīng)該都被 blocked 住的。

總結(jié)

• Hadoop 的 IPC 是一個比較輕量級別的 RPC
• 從代碼來看，只支撐 java 進程之間的通信
• 從沒有重試機制、一個Client 只有一個連接的機制來看，適合與應(yīng)用網(wǎng)絡(luò)環(huán)境較好的場景，適合同機架或者同機房的集群。

P.S. 看了一下 io 包中，其實有個 retry 的 package，里面就是一個重試機制。新鮮的是為啥這個 package 被包含在 io package 中。