因为某些原因需要把前一段时间对Hadoop（版本基于0.20.2）的学习积累搬到这里，成为一个系列。写得会很简单，只为必要时给自己提醒。
IPC框架
所有Hadoop协议接口的实现都依赖Hadoop IPC；
Hadoop IPC的目标是通过RPC完成调用者（RPC::Invoker）对被调用者（RPC::Server）的方法调用，核心是对调用（即RPC::Invocation）的传递；
一个RPC客户端可以通过getProxy方法获取到RPC::Invoker，Invoker本质上是一个（is-a）客户端Client；Client将对RPC Server的方法调用封装为一个请求Call；在另一端，Hadoop的RPC服务器通过getServer方法获取到可提供协议接口（VersionedProtocol）方法实现的Server，方法的实现依赖将请求（Call）解析为调用（Invocation）后进行反射；
Client为每个连接构造一个Connection对象，以维护与连接有关的信息；Client将Call通过Connection传递给相应的Server；在Connection上，头部ConnectionHeader包含一些协议无关的信息，比如用户信息ugi、认证信息等。
服务器模型
Hadoop IPC框架中的Server采用了线程池的服务器模型，请求处理流程如上图。
Listener线程负责监听服务端口，为为进入的请求创建连接，并交给Reader线程处理；
Reader线程从连接中读出请求，放入callQueue队列；
Handler线程从callQueue队列中取出请求，解析请求的内容，调用相应的接口实现，将response内容交给Responder线程；
Responder线程负责将response送出。
Reader的个数由ipc.server.read.threadpool.size决定，默认为1；（为什么默认只使用1个reader？猜测因jvm 1.6开始epoll已经成为默认的nio selector，1个就够了）
Handler的个数在服务器创建时由具体的应用服务器传参，Namenode的handler个数由dfs.namenode.handler.count决定，默认为10；Datanode的handler个数由dfs.datanode.handler.count决定，默认为3；JobTracker的handler个数由mapred.job.tracker.handler.count决定，默认为10；TaskTracker的handler个数由map/reduce slot个数决定，是2倍的最大slot数；
callQueue的长度由handler个数及ipc.server.handler.queue.size决定，默认是handler*100，即平均为每个handler队列100个call。