RPC调用处理请求结果可以分为两部分：
- 获取 response
- 关联 request 和 response
这么分看起来似乎很奇怪，不是直接等待处理完获取结果就行了吗？
我们说 RPC 调用都是在模拟这个动作： Result result = service.call(args); 但是远程调用毕竟不是本地调用（其实稍后可以看到还是有相似之处的），将请求写到网络之后，就无法命令远端做任何事了，这次请求就已经告一段落了。
pigeon client 只知道：
- 向网络写数据；
- 就是写 request
- 处理网络写入的数据；
- 处理成 response
于是不难理解为何有此一问：网络另一端写过来的数据，我怎么知道是哪个请求的返回值呢？
获取 response
其实从网络读取数据，转化成 Object。 pigeon 基于 netty，获取 response 就是处理网络写入。
具体实现在：
// com.dianping.pigeon.remoting.netty.invoker.NettyClientHandler#messageReceived
@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
CodecEvent codecEvent = (CodecEvent) e.getMessage();
if (codecEvent.isValid() && codecEvent.getInvocation() != null) {
client.processResponse((InvocationResponse) codecEvent.getInvocation());
}
}
从 netty 封装 MessageEvent 转换成 CodecEvent，再剥开一层就是 InvocationResponse，当然这还是一个比较泛化的返回值，com.dianping.pigeon.remoting.invoker.process.ResponseProcessor 将会进一步处理；
继续往下看：
// com.dianping.pigeon.remoting.invoker.process.threadpool.ResponseThreadPoolProcessor#doProcessResponse
public void doProcessResponse(final InvocationResponse response, final Client client) {
Runnable task = new Runnable() {
public void run() {
ServiceInvocationRepository.getInstance().receiveResponse(response);
}
};
try {
responseProcessThreadPool.execute(task);
} catch (RejectedExecutionException e) {
String error = String.format("process response failed:%s, processor stats:%s", response,
getProcessorStatistics());
throw new RejectedException(error, e);
}
}
这里封装成了一个 task，交给线程池处理。
再下一层：
// com.dianping.pigeon.remoting.invoker.service.ServiceInvocationRepository#receiveResponse
public class ServiceInvocationRepository {
// 略
private static Map<Long, RemoteInvocationBean> invocations = new ConcurrentHashMap<Long, RemoteInvocationBean>();
public void receiveResponse(InvocationResponse response) {
RemoteInvocationBean invocationBean = invocations.get(response.getSequence());
if (invocationBean != null) {
if (logger.isDebugEnabled()) {
logger.debug("received response:" + response);
}
InvocationRequest request = invocationBean.request;
try {
Callback callback = invocationBean.callback;
if (callback != null) {
Client client = callback.getClient();
if (client != null) {
ServiceStatisticsHolder.flowOut(request, client.getAddress());
}
callback.callback(response);
callback.run();
}
} finally {
invocations.remove(response.getSequence());
}
}
}
// 略
}
这里可以看到， RemoteInvocationBean invocationBean = invocations.get(response.getSequence()); invocations 维护一个 HashMap，key 是一个 long 型的 sequenceId，通过这种方式定位到 invocationBean，而 invocationBean 看实现可知持有 request 引用，以及一个处理返回值的 callback。
Callback 在不同调用模式（sync / future/ oneway/ callback） 下有不同实现类，比如 sync 模式下：
// public class CallbackFuture implements Callback, CallFuture {
@Override
public void callback(InvocationResponse response) {
this.response = response;
}
sync 和 future 调用，都是将 response 对象实例设置给相应的引用
何时得到真正的 returnValue？
看动态代理的逻辑，com.dianping.pigeon.remoting.invoker.service.ServiceInvocationProxy#invoke
在 com.dianping.pigeon.remoting.invoker.process.filter.InvocationInvokeFilter 挨个执行完之后，提取返回值
// com.dianping.pigeon.remoting.invoker.service.ServiceInvocationProxy#extractResult
public Object extractResult(InvocationResponse response, Class<?> returnType) throws Throwable {
Object responseReturn = response.getReturn();
// ...
}
拿到的是顶层父类实例 Object，具体的类型匹配需要客户端和服务端自行匹配
关联 request 和 response
从上面的分析可以看出，关键点就在于 sequence，每次调用应该有个唯一的 id 进行匹配
这个 sequence 是唯一的吗？
如果不唯一，就可能导致拿到错误的处理结果。
sequence 的生成位置
//com.dianping.pigeon.remoting.invoker.process.filter.ContextPrepareInvokeFilter#initRequest
private static AtomicLong requestSequenceMaker = new AtomicLong();
request.setSequence(requestSequenceMaker.incrementAndGet() * -1);
可以看到 这个 sequence 是全局唯一的，准确说是同一个 JVM 中是唯一的，而且是 long 类型，足够大；
Q：sequence 发生回绕怎么办？
A：long 类型，即使发生回绕，也需要足够长的时间，一般来说不会堆积有那么多的请求，导致两个相同的 sequenceId 实际对应不同请求；
分布式环境下，sequenceId 在多个机器上可能重复，会出错吗？
A：sequence 存储的 com.dianping.pigeon.remoting.invoker.service.ServiceInvocationRepository#invocations也是同一个 JVM 唯一的，所以只需要担心会不会有这样的场景：
client A 调用 server A，client B 也调用 server A，但是 server A 把 client B的请求返回值处理之后发送到了 client A？
看看服务端的处理，写返回值：
//com.dianping.pigeon.remoting.provider.process.filter.WriteResponseProcessFilter#invoke
public InvocationResponse invoke(ServiceInvocationHandler handler, ProviderContext invocationContext)
throws Throwable {
try {
ProviderChannel channel = invocationContext.getChannel();
InvocationRequest request = invocationContext.getRequest();
InvocationResponse response = handler.handle(invocationContext);
if (request.getCallType() == Constants.CALLTYPE_REPLY) {
invocationContext.getTimeline().add(new TimePoint(TimePhase.P));
channel.write(invocationContext, response);
invocationContext.getTimeline().add(new TimePoint(TimePhase.P));
}
// ...
channel 就是对socket的封装，可以看成是 client / server 对对方的抽象。
那么只需要保证拿到正确的 channel 就对了：
//com.dianping.pigeon.remoting.netty.provider.NettyServerHandler#messageReceived
public void messageReceived(ChannelHandlerContext ctx, MessageEvent message) {
CodecEvent codecEvent = (CodecEvent) (message.getMessage());
if (!codecEvent.isValid() || codecEvent.getInvocation() == null) {
return;
}
InvocationRequest request = (InvocationRequest) codecEvent.getInvocation();
ProviderContext invocationContext = new DefaultProviderContext(request, new NettyServerChannel(ctx.getChannel()));
//...
}
也就是说，再 client 端 writeRequest() 之后，server 端读取网络数据的时候就从 context 中获取到 client 所在的 channel 了，简单来说，”从哪里来，到哪里去“。
总的来说，不会发生以上所述的 sequenceId 错乱的问题。
