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

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

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

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

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

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

通過 RPC 這個(gè)門面：

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

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

序列化

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

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

一些問題和思考

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

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

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

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

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

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

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

總結(jié)

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

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