spark内核解析——spark通信架构

更好的理解spark——spark通信架构

此篇摘抄自某教程的ppt，希望大家可以更深刻的理解spark

• spark既然是分布式集群，那么他的master和worker节点之间是怎么进行通信的？
• spark1.3之前的通信框架是什么？之后为什么不使用这个通信框架了？

1、Spark内部的通信架构使用Actor模型进行开发，在Spark1.3之前直接使用AKKA来作为具体的通信框架。为了解决shuffle过程大数据量传输的问题，通过引入Netty来开发了一套完全支持Actor模型的通信架构，故在Spark1.6之后，你可以通过配置来选择使用AKKA或者Netty来作为通信架构。在Spark2.0之后，spark只支持Netty作为通信架构。什么原因？1、Akka不同版本之间不兼容的问题，2、Spark的快速发展，Akka跟不上。

2、对于Netty开发的通信架构

1、RpcEndPoint代表一个Actor，就是通信的端点。
2、inbox，一个通信端点具有一个唯一的inbox、用于接收外部的消息。
3、一个通信端点具有多个outbox，用于将消息发送到不同的接收端点中。
4、一个通信端点具有一个transportserver，用于接收外部端点通过transportclient发送过来的数据。
5、对于一个outbox就具有一个transportClient，用于将消息发送到远端的transportserver。
6、一个通信端点就有一个Dispatcher，用于进行内部的消息分发。
7、整个模型就相当于一个邮局系统。异步的通信架构。

设计思路理解：

1. RpcEndpoint：RPC端点 ，Spark针对于每个节点（Client/Master/Worker）都称之一个Rpc端点 ,且都实现RpcEndpoint接口，内部根据不同端点的需求，设计不同的消息和不同的业务处理，如果需要发送（询问）则调用Dispatcher
2. RpcEnv：RPC上下文环境，每个Rpc端点运行时依赖的上下文环境称之为RpcEnv
3. Dispatcher：消息分发器，针对于RPC端点需要发送消息或者从远程RPC接收到的消息，分发至对应的指令收件箱/发件箱。如果指令接收方是自己存入收件箱，如果指令接收方为非自身端点，则放入发件箱
4. Inbox：指令消息收件箱，一个本地端点对应一个收件箱，Dispatcher在每次向Inbox存入消息时，都将对应EndpointData加入内部待Receiver Queue中，另外Dispatcher创建时会启动一个单独线程进行轮询Receiver Queue，进行收件箱消息消费
5. OutBox：指令消息发件箱，一个远程端点对应一个发件箱，当消息放入Outbox后，紧接着将消息通过TransportClient发送出去。消息放入发件箱以及发送过程是在同一个线程中进行，这样做的主要原因是远程消息分为RpcOutboxMessage, OneWayOutboxMessage两种消息，而针对于需要应答的消息直接发送且需要得到结果进行处理
6. TransportClient：Netty通信客户端，根据OutBox消息的receiver信息，请求对应远程TransportServer
7. TransportServer：Netty通信服务端，一个RPC端点一个TransportServer,接受远程消息后调用Dispatcher分发消息至对应收发件箱
   注意：
   TransportClient与TransportServer通信虚线表示两个RpcEnv之间的通信，图示没有单独表达式
   一个Outbox一个TransportClient，图示没有单独表达式
   一个RpcEnv中存在两个RpcEndpoint,一个代表本身启动的RPC端点，另外一个为 RpcEndpointVerifier