已经有文章描述RPC的具体结构，http://caibinbupt.javaeye.com/blog/280790，这篇文章很清晰的描述了Client和Server的结构，但是较为高屋建瓴，我在看的时候依然觉得无法清晰理解其调用过程，所以将过程整理出来，知道how，才容易理解why，即知道是怎么干的，才容易理解为什么会那么去设计。
客户端C要发起向服务端S的关于方法M调用
1. C首先创建一个通向S的连接getConnection，然后将此次调用放入CallList里，这样客户端就可以同时发生很多调用，每个调用用ID来识别。
2. 发送调用参数。调用参数是Client的调用方（比如NameNode，DataNode等）指定的，一般就是一个Invocation对象，里面包含要调用的方法和参数。了解JAVA动态代理类java.lang.reflect.Proxy会对这里的理解有很大帮助。
3. 等待调用结果.Client.Connection是个线程类，启动了之后唯一做的时候就是等待调用结果
对于服务器端，其有一个方法start指定了启动服务器开始监听，这个start被四个类调用，分别是
TaskTracker.initialize，Namenode.initialize,Jobtracker.offerService,
Datanode.startDatanode
显然，任何两者之间的通信都是考这个client-server模型实现的。
server start后，干了三件事
1. 启动listen，监听客户端Call
2. 启动response，随时准备将处理结果发回client
3. 启动10个handler，处理具体的请求。
这里必须对java NIO机制了解，才能看的明白。
当客户端调用来到的时候
1. listen首先将调用doaccept将Connection附加给selectionkey，然后调用doread添加，doread会调用Connecton的方法将调用添加到调用列表，该列表是BlockingQueue，其保持列表先进先出的特性而且支持同步
2. listen将call添加到calllist后，handler因为一直在检测calllist，于是其立刻开始处理，处理完毕后，其将结果保存在call对象中，然后调用response开始向客户端写。这里hadler调用的call只是一个未实现的方法，具体实现在RPC.Server中，这点需要注意。
3. Response也监视responselist，如果responselist中某个call需要将结果写入客户端，就写出，当某个call的结果被发送完毕，从responselist中删除该call对象。
这里有个细节：handler完成call之后就开始向客户端写call结果，但是结果可能太多，无法通过一次性发送完毕，而发送之后还要等待client接受完毕才能再发，如果现在handler在那里等待客户端接受完毕，然后再发，效率不高。解决办法是handler处理完毕之后，只向client发送一次处理结果。如果这一次将处理结果发送完毕，接下来就没有response的事情了，如果没有发送完毕，接下来response负责将剩下的处理结果发送给客户端。这样handler的并发量会大一些。
服务器实现中大量利用监视队列，比如handler就直观坚持calllist，一旦发现数据就开始处理，而response就监视responselist，发现数据需要发送就开始发送。
写完了之后，觉得写的也不清楚，可能要清晰明白只能自己看代码吧。
还发现在没用过java的情况下看hadoop可以更快的学习java
阅读(2015) | 评论(0) | 转发(0) |
