年前的时候系统梳理了一下hbase rpc的实现，并且对组里的小伙伴做了一次分享。趁着热乎劲还没完全消失殆尽，准备赶紧记录下来。
hbase中rpc概况
作为一个分布式系统，hbase的设计是典型的master-salve架构。hbase中主要有master，regionserver，client这三个角色。这三个角色之间rpc的调用关系可以用下图来描述。
client
client有很多，比方说：hbase shell， Java client API等。client没有提供任何rpc服务，它只是调用RegionServer或者master提供的服务。
Master
master主要实现了MasterService和RegionServerStatus协议，分别供Client和RegionServer调用。
MasterService
MasterService主要定义了获取集群状态，以及获取表的元信息，添加/删除列，assign region， enable/disable table，负载均衡等DML相关的一些服务。而Master提供了对这些服务的实现，并且供客户端去调用。比方说，当我们在hbase shell中运行enable/disable table等相关的命令时，client会首先将该rpc请求发送到master。
RegionServerStatus
RegionServerStatus主要定义了regionserver向master汇报集群状态，regionserver启动向master发送rpc请求等相关的服务，而master根据这些rpc请求信息，可以了解整个集群中regionserver的状态。
ReginServer
RegionServer主要实现了AdminService和ClientService协议，供client端调用。而与此同时，ReginServer也会调用RegionServerStatus服务，将相关信息汇报给master。
AdminService
AmdinService主要定义了获取table Regin信息，操作region（Open,Flush,Split，Compact， Merge等）相关服务。
ClientService
ClientService主要定了获取数据，更新，添加数据，Scan等相关的服务。
问题
通过上图，我们发现Master分别提供了对Client和RegionServer的Rpc服务，但是RegionServer却只提供了对client的Rpc服务，而没有提供对Master的rpc的服务。那么当Master怎么向Client发送请求的呢？比方说master启动负载均衡时，需要让regionServer移动region。
答案其实就是通过zookeeper。那为什么会这样呢？
对于整个问题一个可能的解释是：当Master向RegionServer传递信息时，可能需要向多台reginserver传递信息。而通过zookeeper中的node简单变化主动通知regionserver可能更好。（分享时，组里的小伙伴给出的解析，感觉确实是这样）。
Client端rpc实现
使用方式
client发起远程调用时，首先生成一个RpcClient的实例（具体实现类是RpcClientImpl），然后调用call参数（传入方法名称，参数等）。代码实例如下：
|
1
2
|
RpcClient client = new RpcClientImpl(conf, HConstants.CLUSTER_ID_DEFAULT);
client.call(...)
|
client rpc流程
client端rpc实现的主要流程如下图：
主要分为以下几个步骤：
1，client调用call方法后，首先会把传入的参数封装成Call对象（该对象包含方法名称，调用参数，连接地址等信息），并且根据该对象获取连接信息。client端有一个Map对象connections，缓存了连接信息。如果之前有对应的连接则直接获取，否则新建连接并且缓存起来。
2，client端通过调用sendCall函数，生成CallFuture对象，并且将该对象push到CallsToWrite队列中。然后便一直等待本地调用是否成功返回，无论结果如何都将删除之前在callSender中创建的CallFuture对象，然后把结果包装成Pair<message, cellscanner="">返回。
3，另一方面，CallSender线程持续从CallsToWrite队列中获取步骤2中push进去的对象，生成Request请求发送到server端，并且把当前的call对象push到connection的calls中。
4，此后，Connection中run方法持续从步骤3的calls队列读取已发送的请求，检查结果是否从server返回，一旦返回将构造对应的response保存到call中。
Server端Rpc实现
server的实现相比较client端要复杂很多。server端rpc的实现的原理主要是基于异步事件响应设计。主要流程如下图所示：
1，server端的实现逻辑主要封装在rpcserver对象中，在该对象中，首先有一个Listener对象，负责监控连接请求，一旦有连接，Lister会选择一个Reader，并且在新建的连接上注册OP_READ时间，封装中Connection对象。一般只有一个Listener对象。
2，Reader首先从连接中读取数据，最终构造成callRunner，交由调度器调度。rpcserver对象中一般会有多个Reader对象。
3，根据调度器选择的一个callRunner对象，调用CallRunner：Run->RpcServer:call，从而调用具体函数的实现。
4，函数返回结果后，包装成response对象，并且通过doResponse函数将当前的Call push到responseQueue中， 而且将当前conn Responder需要写到writingCons中。
5，注册步骤4中writingCons中连接的OP_WRITE事件，从responseQueue中获取call，并且进行处理，将结果的byte流发送出出去。
调度策略
调度的基本设计图如下：
在server实现过程中，讲到调度器，hbase rpc实现了两种调度器（FifoRpcScheduler和SimpleRpcScheduler）。FifoRpcScheduler会直接将CallRunner对象放到线程池中去执行。而SimpleRpcScheduler，会分成三种不同的executor，对于不同的请求，使用的不同的executor去执行。
小结
通过对hbase rpc的梳理总结，算是对hbase rpc有了较为深入的理解。rpc可以认为是hbase这个系统的血液循环系统，熟悉了rpc，对于学习hbase其他部分的实现原理也大有裨益。