rpc源码解析

---

  如前所述,rpc是hadoop节藕各个功能模块的重要工具,相当于神经系统,串联各部分,使用频次最高,因此可以预见,rpc的设计和实现必然简单高效,不然容易出问题.

1 rpc设计和实现逻辑说明

1.1 设计

  Rpc的设计采用常规远程调用的模式,通过socket和tcp协议,在网络间传输.其独有的特点为使用protocol接口来规定服务端提供的方法,并使用谷歌的protobuf来生成相应的类,这么做可视为把整个流程的复杂度降到了最低.

1.2 实现

  实现上分为三大类,首先是客户端,客户端获取服务端的代理来直接调用其服务.第二类为protocol类,此类定义了服务端所提供的方法,而且每次客户端只能获取到服务端的一个protocol代理.第三类为服务端,服务端每次也只能实例化一个protocol,供客户端调用.
  客户端发送请求到服务端,服务端启动listener监听请求,然后把请求放入本地队列,由handler从队列中取走请求来处理,处理的结果由responder发送回客户端.服务端和客户端都采用nio的模式,都有超时和重试的配置,和一般的rpc没有本质的区别.
  从设计到实现都把整个流程的复杂度降到了最低,可以说rpc是hadoop各个功能中从设计到实现都是最简单的.

2 调试

  这里的调试根据源码中已有的实现类来设置断点,该类在common中的ipc测试中,如下所示

  如上所示,在ping2方法上打上断点,主要是为了简单期间,也可以在上面的testProtoBufRpc()方法里打断点,效果是一样的.
  进入后,可以看到起了很多线程,如上所述,有listener类,有handler类,等等.

  可以按照其各个方法调用的顺序一步步进入,因为比较简单,这里就省去了这些方法调用树以及重要方法的分析,读者可以自行查看.

3 总结

  Rpc作为hadoop中使用频次最高的功能,其设计和实现必定简单.这里从整体上给出了其设计思路和实现流程,具体的代码比较简单,这里不再详述.
  还有mapreduce没有分析,主要是考虑到这个目前使用的场景已不是很多,多数已被spark所代替.即使编写mr的代码,也比较简单,计算出错的概率极低,可以忽略mr在计算时的问题,因为其设计本身就是用时间换空间.
  Yarn和ha没有分析的原因也给出了,因为在我这里调试难度太大,所以暂不考虑.

4 后续安排

  Hadoop的源码分析到此基本到尾声了,接下来会分析与其关系最为密切的hbase,其次是比mr运算更快的spark,最后是kafka,若有时间会再看看flink.