更好的理解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、整個模型就相當於一個郵局系統。異步的通信架構。
設計思路理解：
- RpcEndpoint：RPC端點 ，Spark針對於每個節點（Client/Master/Worker）都稱之一個Rpc端點 ,且都實現RpcEndpoint接口，內部根據不同端點的需求，設計不同的消息和不同的業務處理，如果需要發送（詢問）則調用Dispatcher
- RpcEnv：RPC上下文環境，每個Rpc端點運行時依賴的上下文環境稱之爲RpcEnv
- Dispatcher：消息分發器，針對於RPC端點需要發送消息或者從遠程RPC接收到的消息，分發至對應的指令收件箱/發件箱。如果指令接收方是自己存入收件箱，如果指令接收方爲非自身端點，則放入發件箱
- Inbox：指令消息收件箱，一個本地端點對應一個收件箱，Dispatcher在每次向Inbox存入消息時，都將對應EndpointData加入內部待Receiver Queue中，另外Dispatcher創建時會啓動一個單獨線程進行輪詢Receiver Queue，進行收件箱消息消費
- OutBox：指令消息發件箱，一個遠程端點對應一個發件箱，當消息放入Outbox後，緊接着將消息通過TransportClient發送出去。消息放入發件箱以及發送過程是在同一個線程中進行，這樣做的主要原因是遠程消息分爲RpcOutboxMessage, OneWayOutboxMessage兩種消息，而針對於需要應答的消息直接發送且需要得到結果進行處理
- TransportClient：Netty通信客戶端，根據OutBox消息的receiver信息，請求對應遠程TransportServer
- TransportServer：Netty通信服務端，一個RPC端點一個TransportServer,接受遠程消息後調用Dispatcher分發消息至對應收發件箱
注意：
TransportClient與TransportServer通信虛線表示兩個RpcEnv之間的通信，圖示沒有單獨表達式
一個Outbox一個TransportClient，圖示沒有單獨表達式
一個RpcEnv中存在兩個RpcEndpoint,一個代表本身啓動的RPC端點，另外一個爲 RpcEndpointVerifier