hadoop RPC從入門到暫時放棄

        最近一直都在看徐鵬寫的《hadoop 2.X HDFS源碼剖析》的第二章關于RPC的部分，表示java這塊的編程功底差的實在是太多了，動態代理勉強還算明白，proto buffer、nio還有java的annotation差的實在太多了，好多地方都看得不是很懂。決定暫時放下這塊，把整本書看完再多寫幾篇關于hadoop RPC的文章了。但是還是寫一寫最近的讀書筆記吧。

    RPC全名remote procedure call，即遠程調用，就像生產上經常用的dubbo一樣，本地進程通過RPC可以像調用本地方法一樣調用遠程的服務。    

    下面通過介紹一個自認為比較完整的RPC流程，談談自己對hadoop RPC 的理解：

        1.首先定義好通信兩端的協議（protocol），其實就是定義好調用的接口，這樣調用者（client）可以知道，應該通過什么樣的函數，傳遞什么樣的參數來發起一個RPC請求，既然是通過網絡傳輸到另一個jvm，那么就需要進行一次序列化，這里hadoop RPC的實現支持多種序列化，有自身提供的序列化方法跟proto buffer的序列化方法，聽說還可以支持其他的序列化方法，例如namenode 與 客戶端通信的ClientProtocol就是使用的后者；

        2.Client端有一個叫做server的ClientNameNodeProtocolTranslatorPB實例，這個類“實現”了ClientProtocol，其實就是將不支持proto buffer的ClientProtocol，轉化成了支持這種序列化方式的ClientNamenodeProtocolPB協，當然這中間涉及到了很多動態代理，過程十分復雜，現在也看的不是很懂；

        3.請求不會這么簡單的發送出去，從hadoop2.X開始namenode就支持高可用了，所以server對象在實例化的時候就要根據配置文件，考慮是否支持高可用，其實就是在active namenode失效的時候可以主動failover到standby 的namenode上，向備用的namenode發送RPC請求；

        4.既然請求是序列化過了的，通過socket傳輸，到了Server端，肯定就要有一次反序列化的過程，就是講ClientNamenodeProtocolPB協議轉化為對應的ClientProtocol協議，然后在調用真正實現了ClientProtocol接口的NameNodeRPCServer的對應方法進行需要的操作，這里Server端使用了nio的編程方式來處理RPC請求。感覺所謂nio就是有一些監聽進程在監聽連接事件，然后將PRC請求放入一個隊列，接著又有很多handler處理隊列中的RPC請求，當然為了網絡傳輸，所有handler的執行結果都是由一個Responder進程完成的。

        以上就是對一次RPC目前能夠做的盡可能詳細的分析了，下面配上一副自己的畫的圖：

        基礎差太多，寫的很渣，希望以后能夠來打自己的臉吧！

                                                                                2017.2.13

                                                        今天二逼節，明天虐狗節，學得又很渣，不開心￣へ￣