Hadoop RPC机制

RPC(Remote Procedure Call Protocol)远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。Hadoop底层的交互都是通过 rpc进行的。例如：datanode和namenode 、tasktracker和jobtracker、secondary namenode和namenode之间的通信都是通过rpc实现的。下面是rpc交互过程图：

RPC server端的实体模型
      上一部分是站在用户的角度，宏观地观察整个调用过程。这节分析下在细节上RPC都有哪些实体。为什么要提到这些实体呢？如果把RPC流程看做流水线的话，这些实体就是一个个做具体工作的工人，如果想深入了解流水线的处理，就得知道每个工作他的职责及概况。

      RPC在客户端的细节不多，只想提一点，就是用户在调用代理对象时RPC是怎样拦截这次调用请求呢。对动态代理清楚的朋友都知道，创建代理对象时需要为它 关联一个InvocationHandler，对代理对象的每次调用都会进入绑定的InvocationHandler中，RPC就从这里获取用户的请 求，这里没有疑点。[关于动态代理]

      需要详细说的是RPC在服务端的模型，它由一系列实体组成，分别负责调用的整个流程。这里也可以用一张图来描述它们


从图上看，各个实体分工明确，各司其职。下面我会一一介绍。
Listener
      监听RPC server的端口，如果客户端有连接请求到达，它就接受连接，然后把连接转发到某个Reader，让Reader去读取那个连接的数据。如果有多个 Reader的话，当有新连接过来时，就在这些Reader间顺序分发。这里需要提到的是，Hadoop0.21版本在支持多Reader时有个bug(JIRA)，如果有Reader在server运行期没被使用，Server进程不能正常关闭
Reader
      Reader的职责就是从某个客户端连接中读取数据流，然后把它转化成调用对象(Call)，然后放到调用队列(call queue)里
Handler
      真正做事的实体。它从调用队列中获取调用信息，然后反射调用真正的对象，得到结果，然后再把此次调用放到响应队列(response queue)里
Responder
      它不断地检查响应队列中是否有调用信息，如果有的话，就把调用的结果返回给客户端。

      整个调用流程中与网络有关的地方都是用NIO来处理的。