hbase rpc这点事
年前的时候系统梳理了一下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其他部分的实现原理也大有裨益。