异步机制（Asynchronous） -- （二）异步消息机制兼谈Hadoop RPC

上篇说了半天，却回避了一个重要的问题：为什么要用异步呢，它有什么样的好处？坦率的说，我对这点的认识不是太深刻（套句俗语，只可意会，不可言传）。还是举个例子吧：
比如Client向Server发送一个request，Server收到后需要100ms的处理时间，为了方便起见，我们忽略掉网络的延迟，并且，我们认为Server端的处理能力是无穷大的。在这个use case下，如果采用同步机制，即Client发送request -> 等待结果 -> 继续发送，那么，一个线程一秒钟之内只能够发送10个request，如果希望达到10000 request/s的发送压力，那么Client端就需要创建1000个线程，而这么多线程的context switch就成为client的负担了。而采用异步机制，就不存在这个问题了。Client将request发送出去后，立即发送下一个request，理论上，它能够达到网卡发送数据的极限。当然，同时需要有机制不断的接收来自Server端的response。

以上的例子其实就是这篇的主题，异步的消息机制，基本的流程是这样的：

如果仔细琢磨的话，会发现这个流程中有两个很重要的问题需要解决：
1. 当client接收到response后，怎样确认它到底是之前哪个request的response呢？
2. 如果发送一个request后，这个request对应的response由于种种原因（比如server端出问题了）一直没有返回。client怎么能够发现类似这样长时间没有收到response的request呢？

对于第一个问题，一般会尝试给每个request分配一个独一无二的ID，返回的Response会同时携带这个ID，这样就能够将request和response对应上了。
对于第二个问题，需要有一个timeout机制，对于每一个request都有一个定时器，如果到指定时间仍然没有返回结果，那么会触发timeout操作。多说一句，timeout机制其实对于涉及网络的同步机制也是非常有必要的，因为有可能client与server之间的链接坏了，在极端情况下，client会被一直阻塞住。

纸上谈兵了这么久，还是看一个实际的例子。我在这里用Hadoop的RPC代码举例。这里需要事先说明的是，Hadoop的RPC对外的接口其实是同步的，但是，RPC的内部实现其实是异步消息机制。多说无益，直接看代码吧（讨论的所有代码都在org.apache.hadoop.ipc.Client.java 里）：

public Writable call(Writable param, ConnectionId remoteId) throws InterruptedException, IOException { //具体的代码一会再看... }

这就是Client.java对外提供的接口。一共有两个参数，param是希望发送的request，remoteId是指远程server对应的Id。函数的返回就是response（也是继承自writable）。所以说，这是一个同步调用，一旦call函数返回，那么response也就拿到了。

call函数的具体实现一会再看，先介绍Client中两个重要的内部类：