Spark RPC 到底是个什么鬼？

　　本文会为大家介绍Spark中的RPC通信机制，详细阐述“Spark RPC到底是个什么鬼?”，闲话少叙，让我们来进入Spark RPC的世界!

　　Spark RPC三剑客

　　Spark RPC中最为重要的三个抽象(“三剑客”)为：RpcEnv、RpcEndpoint、RpcEndpointRef，这样做的好处有：

　　对上层的API来说，屏蔽了底层的具体实现，使用方便

　　可以通过不同的实现来完成指定的功能，方便扩展

　　促进了底层实现层的良性竞争，Spark 1.6.3中默认使用了Netty作为底层的实现，但Akka的依赖依然存在;而Spark 2.1.0中的底层实现只有Netty，这样用户可以方便的使用不同版本的Akka或者将来某种更好的底层实现

　　下面我们就结合Netty和“三剑客”来具体分析他们是如何来协同工作的。

　　Send a message locally

　　我们通过Spark源码中的一个Test(RpcEnvSuite.scala)来分析一下发送本地消息的具体流程，源码如下(对源码做了一些修改)：

　　为了方便理解，先把流程图贴出来，然后详细进行阐述：

　　下面我们来详细阐述上例的具体过程：

　　首先是RpcEndpoint创建并注册的流程：(图中的蓝色线条部分)

　　1、创建RpcEndpoint，并初始化rpcEnv的引用(RpcEnv已经创建好，底层实际上是实例化了一个NettyRpcEnv，而NettyRpcEnv是通过工厂方法NettyRpcEnvFactory创建的)

　　2、实例化RpcEndpoint之后需要向RpcEnv注册该RpcEndpoint，底层实现是向NettyRpcEnv进行注册，而实际上是通过调用Dispatcher的registerRpcEndpoint方法向Dispatcher进行注册

　　3、具体的注册就是向endpoints、endpointRefs、receivers中插入记录：而receivers中插入的信息会被Dispatcher中的线程池中的线程执行：会将记录take出来然后调用Inbox的process方法通过模式匹配的方法进行处理，注册的时候通过匹配到OnStart类型的message，去执行RpcEndpoint的onStart方法(例如Master、Worker注册时，就要执行各自的onStart方法)，本例中未做任何操作

　　4、注册完成后返回RpcEndpointRef，我们通过RpcEndpointRef就可以向其代表的RpcEndpoint发送消息

　　下面就是通过RpcEndpointRef向其代表的RpcEndpoint发送消息的具体流程：(图中的红色线条部分)

　　1、2、调用RpcEndpointRef的send方法，底层实现是调用Netty的NettyRpcEndpointRef的send方法，而实际上又是调用的NettyRpcEnv的send方法，发送的消息使用RequestMessage进行封装：

　　3、4、NettyRpcEnv的send方法首先会根据RpcAddress判断是本地还是远程调用，此处是同一个RpcEnv，所以是本地调用，即调用Dispatcher的postOneWayMessage方法

　　5、postOneWayMessage方法内部调用Dispatcher的postMessage方法

　　6、postMessage会向具体的RpcEndpoint发送消息，首先通过endpointName从endpoints中获得注册时的EndpointData，如果不为空就执行EndpointData中Inbox的post(message)方法，向Inbox的mesages中插入一条InboxMessage，同时向receivers中插入一条记录，此处将Inbox单独画出来是为了方便大家理解

　　7、Dispatcher中的线程池会拿出一条线程用来循环receivers中的消息，首先使用take方法获得receivers中的一条记录，然后调用Inbox的process方法来执行这条记录，而process将messages中的一条InboxMessage(第6步中插入的)拿出来进行处理，具体的处理方法就是通过模式匹配的方法，匹配到消息的类型(此处是OneWayMessage)，然后来执行RpcEndpoint中对应的receive方法，在此例中我们只打印出这条消息(步骤8)

　　至此，一个简单的发送本地消息的流程执行完成。

　　什么，上面的图太复杂了?我也觉得，下面给出一张简洁的图：

　　我们通过NettyRpcEndpointRef来发出一个消息，消息经过NettyRpcEnv、Dispatcher、Inbox的共同处理最终将消息发送到NettyRpcEndpoint，NettyRpcEndpoint收到消息后进行处理(一般是通过模式匹配的方式进行不同的处理)

　　如果进一步的进行抽象就得到了我们刚开始所讲的“三剑客”：RpcEnv、RpcEndpoint、RpcEndpointRef

　　RpcEndpointRef发送消息给RpcEnv，RpcEnv查询注册信息将消息路由到指定的RpcEndpoint，RpcEndpoint接收到消息后进行处理(模式匹配的方式)

　　RpcEndpoint的声明周期：constructor - onStart - receive* - onStop

　　其中receive*包括receive和receiveAndReply

　　本文我们只是通过一个简单的测试程序分析了Spark Rpc底层的实现，集群中的其它通信(比如Master和Woker的通信)的原理和这个测试类似，只不过具体的发送方式有所不同(包括ask、askWithRetry等)，而且远程发消息的时候使用了OutBox和NIO等相关的内容，感兴趣的朋友可以对源码进行详细的阅读，本文不一一说明，目的就是通过简单的测试理解大致流程，不再为“Spark Rpc到底是什么”而纠结，一句话总结：Spark Rpc就是Spark中对分布式消息通信系统的高度抽象。