superhedantou

 前段时间看spark,看着迷迷糊糊的。最近终于有点头绪,先梳理了一下spark rpc相关的东西,先记录下来。

1,概述

个人认为,如果把分布式系统(HDFS, HBASE,SPARK等)比作一个人,那么RPC可以认为是人体的血液循环系统。它将系统中各个不同的组件(如Hbase中的master, Regionserver, client)联系了起来。同样,在spark中,不同组件像driver,executor,worker,master(stanalone模式)之间的通信也是基于RPC来实现的。

Spark 1.6之前,spark的RPC是基于Akaa来实现的。Akka是一个基于scala语言的异步的消息框架。Spark1.6后,spark借鉴Akka的设计自己实现了一个基于Netty的rpc框架。大概的原因是1.6之前,RPC通过Akka来实现,而大文件是基于netty来实现的,加之akka版本兼容性问题,所以1.6之后把Akka改掉了,具体jira见(https://issues.apache.org/jira/browse/SPARK-5293)。

本文主要对spark1.6之后基于netty新开发的rpc框架做一个较为深入的分析。

2,整体架构

spark 基于netty新的rpc框架借鉴了Akka的中的设计,它是基于Actor模型,各个组件可以认为是一个个独立的实体,各个实体之间通过消息来进行通信。具体各个组件之间的关系图如下(图片来自[1]):

2.1 RpcEndpoint

表示一个个需要通信的个体(如master,worker,driver),主要根据接收的消息来进行对应的处理。一个RpcEndpoint经历的过程依次是:构建->onStart→receive→onStop。其中onStart在接收任务消息前调用,receive和receiveAndReply分别用来接收另一个RpcEndpoint(也可以是本身)send和ask过来的消息。

2.2 RpcEndpointRef

RpcEndpointRef是对远程RpcEndpoint的一个引用。当我们需要向一个具体的RpcEndpoint发送消息时,一般我们需要获取到该RpcEndpoint的引用,然后通过该应用发送消息。

2.3 RpcAddress

表示远程的RpcEndpointRef的地址,Host + Port。

2.4 RpcEnv

RpcEnv为RpcEndpoint提供处理消息的环境。RpcEnv负责RpcEndpoint整个生命周期的管理,包括:注册endpoint,endpoint之间消息的路由,以及停止endpoint。

 

3,实现

Rpc实现相关类之间的关系图如下(图片来自[2]):

核心要点如下:

1,核心的RpcEnv是一个特质(trait),它主要提供了停止,注册,获取endpoint等方法的定义,而NettyRpcEnv提供了该特质的一个具体实现。

2,通过工厂RpcEnvFactory来产生一个RpcEnv,而NettyRpcEnvFactory用来生成NettyRpcEnv的一个对象。

3,当我们调用RpcEnv中的setupEndpoint来注册一个endpoint到rpcEnv的时候,在NettyRpcEnv内部,会将该endpoint的名称与其本省的映射关系,rpcEndpoint与rpcEndpointRef之间映射关系保存在dispatcher对应的成员变量中。

 

接下来,我们看一个具体的案例:在standalone模式中,worker会定时发心跳消息(SendHeartbeat)给master,那心跳消息是怎么从worker发送到master的呢,master又是怎么接收消息的?

1,在worker中,forwordMessageScheduler线程会定时每隔心跳超时时间的四分之一时间向自己发送SendHeartbeat消息,在worker的receive函数中,我们看到一旦接收到SendHeartbeat消息,worker会调用sendToMaster函数,将Heartbeat消息(包含worker Id和当前worker的rpcEndpoint引用)发送给master。

2,在worker的sendToMaster函数中,通过masterRef.send(message)将消息发送出去。那这个调用背后又做了什么事情呢?NettryRpcEnv中send的实现如下:

 

可以看到,当前发送地址(nettyEnv.address),目标的master地址(this)和发送的消息(SendHeartbeat)被封装成了RequestMessage消息,如果是远程rpc调用的话,最终send将调用postToOutbox函数,并且此时消息会被序列化成Byte流。

3,在postToOutbox函数中,消息将经过OutboxMessage中的sendWith方法(client.send(content)),最终通过TransportClient的send方法(client.send(content)),而在TransportClient中将消息进一步封装,然后发送给master。

 

4, 在master端TransportRequestHandler的handle方法中,由于心跳信息在worker端被分装成了OneWayMessage,所以在该handle方法中,将调用processOneWayMessage进行处理。

 

 

5,processOneWayMessage函数将调用rpcHandler的实现类NettyRpcEnv中的receive方法。在该方法中,首先通过internalRecieve将消息解包成RequestMessage。然后该消息通过dispatcher的分发给对应的endpoint。

 

6,那消息是怎么分发的呢?在Dispatcher的postMessage方法中,可以看到,首先根据对应的endpoint的EndpointData信息(主要是该endpoint及其应用以及其信箱(inbox)),然后将消息塞到给endpoint(此例中的master)的信箱中,最后将消息塞到recievers的阻塞队列中。

7,那队列中的消息是怎么被消费的呢?在Dispatcher中有一个线程池threadpool在MessageLoop类的run方法中,将receivers中的对象取出来,交由信箱的process方法去处理。如果没有收到任何消息,将会阻塞在take处。

 

8,在inbox的proces方法中,首先取出消息,然后根据消息的类型(此例中是oneWayMessage),最终将调用endpoint的receiver方法进行处理(也就是master中的receive方法)。至此,整个一次rpc调用的流程结束。

 

4,小结

本文主要对rpc的历史,初始实现思想以及一次rpc的具体流程做了一个较为深入的分析。此外,对spark rpc实现涉及的一部分类也做了一个概括性说明。这也是一个开始,解下来,会陆续对spark的一些内部原理做较为深入的分析。

 

 

 

 

 

 

 

 

[1] https://wongxingjun.github.io/2016/12/08/Spark-RPC%E8%A7%A3%E8%AF%BB/

[2] http://shiyanjun.cn/archives/1545.html

 

 

分类:

技术点:

相关文章: