最近開始看 Hadoop 的一些源碼，展開hadoop的源碼包，各個組件分得比較清楚，於是開始看一下 IPC 的一些源碼。
IPC模塊，也就是進程間通信模塊，如果是在不同的機器上，那就可以理解爲 RPC 了，也就是遠程調用。事實上， hadoop 中的 IPC 也就是基於 RPC 實現的。
使用 sloccount 統計一下 ipc 包中代碼的行數，一共是 2884 行。也就是說，IPC 作爲hadoop的基礎組件，僅僅用了不到3000行的代碼，就完成得穩定且富有效率。
IPC 中的關鍵類關係：
對用戶而言，可以直接使用的就是綠色的類。
通過 RPC 這個門面：
客戶端可以創建相應的 proxy，接着就可以進行遠程調用。
而服務提供者則可以創建相應的 server，並進行相應的生命週期管理（start、stop），從而提供服務。
序列化
從上圖也可以看出，client 和 server 的交互，是通過網絡 connection， 而走網絡的調用，是需要走序列化/反序列話的過程的。
這個過程， IPC 使用了 Hadoop 的自己的序列化機制，一切都在 Writable 接口中，只要給定 writable 的 DataOutput 和 DataInput，就可以讓 Writable 自己實現序列化。
一些問題和思考
-
client 是單例的嗎 —— 可以理解爲是，但其實不一定。可以跟蹤 getProxy 的代碼，雖然每次都會新建一個代理對象，但底層的 Client 還是和 SocketFactory 對應的。一般默認的，都是使用默認的 SocketFactory， 但如果你設置了 "hadoop.rpc.socket.factory.class.default" ，則會有新的Client與你自定義的 SocketFactory 對應。這時候， client 就不是單例的。
-
client 與同一個 server 有幾個連接 —— 一個 client與一個 server 只有一個連接，具體可以看生成的代理中，有一個 remoteId, 這個 remoteId 是和 client關聯的，client 進行調用的使用，會將此 remoteId 作爲一個 connectionId。因此，一般一個 client 是一個連接。
-
如果 client 是一個連接，那麼對此 client 的調用，不都是串行的嗎？ —— 看你怎麼理解了，在用戶層面，也就是 client 調用的方法，是可以併發的。client 底層是使用一個連接來進可能的完成吞吐量。每個 request 和 response 都會有一個 id 關聯起來。因此一個連接上可以跑滿請求和相應。
-
由於網絡問題，client調用服務失敗後，有重試機制嗎 —— 在IPC中沒有看到call的重試，需要上層去保證了。但是後面的調用會重新建立連接。
-
server 是單例的嗎 —— 不一定。如果你只 getServer 一次的話。創建一個 server 的代價是非常重的。通過上圖你也可以知道，他需要有一個線程 （Listener）來 accept socket，同時需要一些 Reader線程 來進行 socket 的 read，還有一個 Responder 來進行 socket 的 write，另外，還有若干個 handler線程 來進行業務處理。因此，如果可以減少 server 的個數，就應該減少 server 個數。
-
暴露出的服務是否應該是線程安全的 —— 是的，一定要線程安全。server 底層是通過 nio 進行 socket 操作的，因此雖然只有一個線程負責 accept，但是能夠支持很多的client連接。這些連接在到達 server 端之後，很有可能就會併發執行同一方法（如果你的業務handler不止一個的話）
-
一個 server 要消耗多少線程資源？ —— 讓我們來算一下，一個 Listener 線程，若干個 Reader 線程（默認1個），若干個 Handler 線程（在 getServer 的時候指定，一般1 - 10個），一個 Responder 線程。如果都按照默認值來計算的話。最少需要 1 + 1 + 1 + 1 = 4 個線程。也許，不應該算多，如果請求量不大的話，這些線程應該都被 blocked 住的。
