Hadoop中IPC的源碼分析
最近開(kāi)始看Hadoop的一些源碼,展開(kāi) hadoop 的源碼包,各個(gè)組件分得比較清楚,于是開(kāi)始看一下IPC的一些源碼。
IPC模塊,也就是 進(jìn)程間通信模塊,如果是在不同的機(jī)器上,那就可以理解為 RPC 了,也就是遠(yuǎn)程調(diào)用。事實(shí)上, hadoop 中的 IPC 也就是基于 RPC 實(shí)現(xiàn)的。
使用 sloccount 統(tǒng)計(jì)一下 ipc 包中代碼的行數(shù),一共是 2884 行。也就是說(shuō),IPC 作為hadoop的基礎(chǔ)組件,僅僅用了不到3000行的代碼,就完成得穩(wěn)定且富有效率。
IPC 中的關(guān)鍵類(lèi)關(guān)系:
對(duì)用戶(hù)而言,可以直接使用的就是綠色的類(lèi)。
通過(guò) RPC 這個(gè)門(mén)面:
- 客戶(hù)端可以創(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 的交互,是通過(guò)網(wǎng)絡(luò) connection, 而走網(wǎng)絡(luò)的調(diào)用,是需要走序列化/反序列話(huà)的過(guò)程的。
這個(gè)過(guò)程, IPC 使用了 Hadoop 的自己的序列化機(jī)制,一切都在 Writable 接口中,只要給定 writable 的 DataOutput 和 DataInput,就可以讓 Writable 自己實(shí)現(xiàn)序列化。
一些問(wè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 與同一個(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)用,不都是串行的嗎? —— 看你怎么理解了,在用戶(hù)層面,也就是 client 調(diào)用的方法,是可以并發(fā)的。client 底層是使用一個(gè)連接來(lái)進(jìn)可能的完成吞吐量。每個(gè) request 和 response 都會(huì)有一個(gè) id 關(guān)聯(lián)起來(lái)。因此一個(gè)連接上可以跑滿(mǎn)請(qǐng)求和相應(yīng)。
-
由于網(wǎng)絡(luò)問(wèn)題,client調(diào)用服務(wù)失敗后,有重試機(jī)制嗎 —— 在IPC中沒(méi)有看到call的重試,需要上層去保證了。但是后面的調(diào)用會(huì)重新建立連接。
-
server 是單例的嗎 —— 不一定。如果你只 getServer 一次的話(huà)。創(chuàng)建一個(gè) server 的代價(jià)是非常重的。通過(guò)上圖你也可以知道,他需要有一個(gè)線(xiàn)程 (Listener)來(lái) accept socket,同時(shí)需要一些 Reader線(xiàn)程 來(lái)進(jìn)行 socket 的 read,還有一個(gè) Responder 來(lái)進(jìn)行 socket 的 write,另外,還有若干個(gè) handler線(xiàn)程 來(lái)進(jìn)行業(yè)務(wù)處理。因此,如果可以減少 server 的個(gè)數(shù),就應(yīng)該減少 server 個(gè)數(shù)。
-
暴露出的服務(wù)是否應(yīng)該是線(xiàn)程安全的 —— 是的,一定要線(xiàn)程安全。server 底層是通過(guò) nio 進(jìn)行 socket 操作的,因此雖然只有一個(gè)線(xiàn)程負(fù)責(zé) accept,但是能夠支持很多的client連接。這些連接在到達(dá) server 端之后,很有可能就會(huì)并發(fā)執(zhí)行同一方法(如果你的業(yè)務(wù)handler不止一個(gè)的話(huà))
-
一個(gè) server 要消耗多少線(xiàn)程資源? —— 讓我們來(lái)算一下,一個(gè) Listener 線(xiàn)程,若干個(gè) Reader 線(xiàn)程(默認(rèn)1個(gè)),若干個(gè) Handler 線(xiàn)程(在 getServer 的時(shí)候指定,一般1 - 10個(gè)),一個(gè) Responder 線(xiàn)程。如果都按照默認(rèn)值來(lái)計(jì)算的話(huà)。最少需要 1 + 1 + 1 + 1 = 4 個(gè)線(xiàn)程。也許,不應(yīng)該算多,如果請(qǐng)求量不大的話(huà),這些線(xiàn)程應(yīng)該都被 blocked 住的。
總結(jié)
- Hadoop 的 IPC 是一個(gè)比較輕量級(jí)別的 RPC
- 從代碼來(lái)看,只支持 java 進(jìn)程之間的通信
- 從沒(méi)有重試機(jī)制、一個(gè) Client 只有一個(gè)連接的機(jī)制來(lái)看,適合與應(yīng)用網(wǎng)絡(luò)環(huán)境較好的場(chǎng)景,適合同機(jī)架或者同機(jī)房的集群。
P.S. 看了一下 io 包中,其實(shí)有個(gè) retry 的 package,里面就是一個(gè)重試機(jī)制。奇怪的是為啥這個(gè) package 被包含在 io package 中。